@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 发展的好。因为企业级开发就是要条条框框限制死

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

那是青春呀 居然 4 了 看看

主要是你这个项目比较尴尬 稍微大点公司都自己造轮子了

没有大公司背书，不能产生影响

其实 618 并不是 6.18 那一天最便宜 你发现降价幅度很大就差不多了