@axihe 这种就是得封呀

到你频道刷你想着技术方案屏蔽他，但他肯定不是只在你频道，非技术 up 主都不知道怎么封他，这种就是劣币，封了才好

研究生老板简直比比资本主义还资本主义

工作了还可以辞职，找下家。

没办法，自身实力不够硬，只能舔着老板

@NightTeam 机器 ID 用内网 ip 或者机器名转换下就行，可以引入 zk 或者 redis，只是用来做一个启动的时候发号器（ docker 场景），这种做法也很常见

会有低位溢出问题，这个就需要你自己算好，如果机器是预期的的，可以缩小机器 id 使用的位数，再加上评估业务 qps，基本上毫秒内的自增是够用的

只是 Snowflake 有两个明显缺点：1.趋势递增（非严格递增，这个需要看业务了 2.时间回拨问题（目前简单规避的方法是 sleep，跳过这回拨的几十 ms

不是说楼主这个有什么致命的问题，自己业务用也没啥问题。但要是把这个东西拿出来说（分享），反正在我们公司要做好被 challenge 的准备

@NightTeam 高可用的话需要多机房、多存储，以及合理的重试策略、降级策略

@NightTeam "它自行按照自己的序号来生成，同一时间不同机器生成的 ID 必定是重复且不递增的" 没啊，机器号不是在系列号的相对高位嘛 即使时间一样、序列号一样 生成的最终 id 也不一样呀 难道我一直用错了？

这事我还真和女朋友讨论过，最终结论：两个孩子不一样的姓可能感觉对孩子不好，造成割裂（会有潜移默化的影响
还有就是谁承担更多责任就跟谁姓

@NightTeam “另外，提到 Redis 不靠谱、容易出问题，我猜你平时不用 Redis ？”

我感觉是你没有大规模用过
我说的 redis 不稳定是 redis 这一套链路不稳定，故障的原因很多，单一性不稳定。3 个 9 不是很高，我上层业务要 4 个 9 怎么办？至少得双存储

“你提到的每个实例模块都引入 jar 包的方式（我不懂 Java，不好乱评价）还能保证各个节点生成的 ID 不重复，那真是太厉害了”
不懂 java 没关系呀，就是类似 go import 一个包
你自己也说了“中下位占 10 bit，值为工作机器的 ID，值的上限为 1024” 每个机器 id 不一样 生成的肯定能保证不重复呀

时钟回拨是个问题，但你的做法只是用 redis 来代替本地时间，这个可靠性是降了几个数量级的

看业务吧 支付的话其实不是那么太关注性能，毕竟得先抢到嘛
建议 php-fpm，虽然我自己用 swoole 做别的系统，但是没有个能人是 hold 不住的，很多非 php 的额外问题

你这个严重依赖 redis 很不靠谱，实际使用中 redis 容易出问题

Snowflake 的好处是这个 jar 包 每个实例模块都可以引入，还能保证各个节点生成的 id 不重复。
你这个是相当于发号中心了

从系统开发上来说 串号（订单）来说还是有可能的。
但 JD 这个处理有点迷，这种问题不是应该高优处理嘛。或者问题并没有到核心开发团队、或者确实有 bug，不愿承认（因为个案问题一般不算作线上问题）

楼主这个真是一言难尽

0. 变量和字符串这也就不说了
1. params 不是 json，是 Python 内置 dict
2. post data=params 也是 post 的 form-data 格式，要 post json 应该写 json=params

我们做个自己加解密 做一层代理

说了这么多主要是太贵了 要是 688 啥的就没这么多问题了

你主要是想区分浏览器和 app native 的请求吧

这个感觉不好区分，要不然你判断是 html 啥的再 302 呗

没事的 上周才去了怀柔，不要聚集就行

细节上不一样 之前便宜的热水壶烧水蒸汽湿一地，插线板就在旁边 感觉有点危险

买了个贵点的好多了

然后百亿补贴是官方的补贴 你看看没有补填的，电子产品啥的也是差不多价格

那肯定呀 百度和微博都在用，不过还是因为太简陋了，社区上没有 laravel 发展的好。因为企业级开发就是要条条框框限制死

这种要联系客服 自动申请价包的不行