这是一个创建于 42 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近遇到个事想和大家分享一下。 我们业务最近出了一个 bug
我这边通过同事的接口获取快递面单 pdf 具体流程是 [包裹号] -> [资源 ID ] -> [快递面单 pdf ]
也就是说： 拿着包裹号请求接口，拿到资源 ID 再用资源 ID 请求下载地址，获取 PDF
然后发现奇怪的事情，包裹 A 和 包裹 B 获取到的快递面单串了，下载下来是一样的单号 资源 ID res_id 是 32 位数，相同一秒获取到的 pdf 就是一样的，猜测是采用 md5(time()) 这种方式命名文件
然后和 同事 A 反馈了该问题，同事 A 反应已经修复 接下来一段时间还是出现这种问题会导致仓库发错货
老板问我咋回事，我又去查日志发现同一时间 res_id 还是会一样的，这次精度有所提升不是秒了，大概精确到后面两位的样子
然后和老板说了一下，是因为资源 id 还是一样的 这里他还改了一下运单文件在他服务器上的保存的命名方式，这个改动压根解决不了这个问题 然后同事 A 说他已经改了，没问题的，你不应该请求速度这么快 我直接整个大无语
然后开会 我说建议使用 sha1(运单号) 的方式生产资源 id ，或者使用 UUID ，还没有说完直接反驳 说不安全巴拉巴拉，不安全可以 accessToken 验证啊，外部访问不到不就可以了 然后又说改算法耗费服务器性能巴拉巴拉的，老板又好声好气的让他想办法改一下 最后他改了，改成 md5(microtime(true))
然后今天又又又出现这个 bug 了，老板又跑过来问我，我已经要疯了 这个问题前前后后几个月都没有弄好
同事 A 是那种反驳性型人格，而且比较自大那种，我快待不下去了
 |
101
EchoTong 42 天前
你为什么要做这个中间人？不让老板直接找他？
|
 |
102
Fallever 42 天前
工作中我总是秉信一个观点： 什么人干什么事。
事能不能做好跟工作了多久关系并不正相关 |
 |
104
ruke 42 天前
懒一点 直接用 Id 来 hash
 |
 |
106
jzphx 42 天前
才疏学浅，才知道还有这种生成 id 的方式
|
 |
107
hefish 42 天前
你得学会甩锅。 光跟我们讲问题有啥用。
|
 |
108
SanjinGG 42 天前
@xz410236056 #59 这种领导纯纯逗逼吧，我顶多排查下问题是那里的，上游改好再跟进，照常到点下班
|
 |
111
Steaven 42 天前
php 不是有 uniqid() 这个方法么
|
 |
114
DefoliationM 42 天前
你不是老板就不要管他，诚心给自己添堵吗？他的问题直接让他自己解决，解决不了就上报说是他问题。老板再问你，你直接三个人拉个群 @他。
|
 |
115
opengg 42 天前 via Android
神经病啊，hash time 作为业务 key
|
|
116
opengg 42 天前 via Android
你们老板是不是拿同事的工资上班啊？你同事是不是才是公司大股东啊？
老板还得跟下属好声好气哄着他干活？干不了来找你？ 这公司是要玩啊 |
 |
117
AkinoKaedeChan 42 天前 via Android
Hmm ，都在讨论怎么生成随机 ID ，我觉得这包裹号好像就是唯一的？
|
 |
119
abolast 41 天前
@coderzhangsan 真的有这样愚蠢的。有个干了不少年的后端，还嘲笑过我在 alpine 里面用 apk 呢而不是 apt-get ，然后觉得我太菜了，笑死我家一大堆路由器的包管理器都是 apk ，无知傲慢是可怕的
|
|
121
abolast 41 天前
@DinnyXu 这看品德素养，我(运维)都用数据复现或者直接告诉他(后端)代码要怎么写能解决，25 年至今打脸不下于 20 次，最后他情绪越来越不稳定，每次对接都直接大声狂吼狂吠我。没关系，我给自己下了个禁制就是绝不看他代码具体内容，在他这我只是个运维
|
 |
122
jiuhuicinv 41 天前
ID 自增？
|
 |
123
whisper1225 41 天前
唯一标志的问题，也是他的问题，不能惯着，这是底线，不然以后有你受的，但是要注意斗争方式
|
 |
124
silyboy 41 天前
人生艰难,别内耗, 自己权衡要不要多走一步. 例如:你已经给出了方案建议, 再进一步就是验证方案的可行性和性能影响. 摆数据讲事实.
|
 |
125
qiany 41 天前
之前写 java 的时候用时间戳生成 id 在并发下很容易出现重复的，你这个不如直接用包裹号加上固定标识
|
 |
126
riceball 41 天前
❌ md5(microtime(true)) 对这样短的字符串冲突比较大，而且耗资源.
✅ microtime + nanoID: https://github.com/hidehalo/nanoid-php （偷懒用） 这个其实是服务器端开发，优化要找到要点，变化的点，然后加顺序号。其他无论如何都要增加额外开销，只是大小不同。 |
 |
128
uuundefined 41 天前
加锁一个自增的计数就是唯一值了。用毫秒适合并发低的场合，还搞 32 位那么长
|
 |
129
SwaggyMacro 41 天前
直接跟领导屌他，臭鲨臂
|
 |
130
esee 41 天前
前面加多一个短的随机字符串应该就没问题了
|
 |
131
skipwitit 41 天前 via iPhone
你们能在一个地方相处 水平也高不到哪里去
|
 |
132
duan602728596 41 天前
哎，我这还遇到明文密码直接从接口里返回来的呢
|
 |
133
soulflysimple123 41 天前
id 不是用雪花算法吗，这都是很成熟的东西
|
 |
134
xxb 40 天前 via iPad
包裹和同事都用 A 命名了，是不是应该使用 uuid 🐶
|
 |
135
unics 40 天前
如果你是乙方，这种事情就是家常便饭，甲方永远不会认为自己出错，总是让乙方修改来适配甲方的错误。
|
 |
136
mingtdlb 40 天前
你这种公司环境，一般混着就行，别想着做好，每次配合排查，证据拿出来，指出问题不在自己这
当然如果你能力强，老板又是有魄力 大方的那种，愿意给你升值加薪，那你可以干他。很明显 你这个老板没魄力，把他干掉，没人顶他的位置。 如果格格不入，那只能自己走，你很难推动解决的。 |
|
137
mingtdlb 40 天前
讲好听点，是研发。难听点，一大帮人都是调参侠、调包仔，他为什么反驳，因为他在自卫啊，水平臭的不行，不自卫按你的方案，他实现不了不是完犊子了。
|
 |
138
realpg PRO @honkew #2
你就不会写一个完整的 外行都能看明白的问题分析报告给老板? 就这个帖子里讲的这些要点 为什么出现这个问题 为什么是同事的问题 为什么不应该用 hash 作为这个 比如 4 楼的答案 形成一个简洁 可找第三方验证的书面报告 5 分钟都用不了 你老板也有能力找一个他认可的技术人员看这个报告说的对不对 不要自己给自己做证据支撑 |
 |
139
spritecn 39 天前
华为 JDK 示例里很多全局变量 ,比如 callId,smsId,哈哈哈哈,抄了就踩坑
|
Select Language