@cue

是的，坐着的时候，双腿最好是垂直落下的，躺着的时候，不要让颈椎弯曲太大

离职……熬夜的打工人个个都萎靡

@lmshl

一个商品只能在一个 shard 上对不对？如果用户提交多个商品并带有跨店满减优惠、代金券，是不是要设计回滚

楼主吐槽的本质其实是不会管理的人在自以为是的管理……
好技术少，好销售更少，很多销售 === 碰运气

@lmshl

也没有说分布式事务（基本也是避免使用分布式事务）。你的性能我并没有异议，stm 没毛病。但是场景更像网络游戏而不是电商。
现实是不可能只用一台服务器去承载所有业务（只用一台服务器的电商业务量相信也用不上你的架构），既然是集群的话，必然就要考虑一致性的问题，秒杀的压力并不在于最终事务，而是在于查询过滤的效率，前面小哥也证明了加锁减库存也不差。

当前基于 nodejs ，改成 java 的原因是啥？
vertx eventbus 发消息是一个一个发……估计和 nodejs 版本也没啥区别
如果性能符合你的要求也没啥问题

@lmshl

举例“限定单个用户购买数量”，一是架构里要涉及商品以外的数据加入到事务内存中增加了项目维护复杂度，二是看集群内存如何保证强一致性。单机跑性能意义真的不大。

@lmshl

意义不大，实际业务场景会涉及到很多，比如限定单个用户购买数量

@la9998372

100m 的词库也太大了吧

很多信息没有给，50ms 的要求也很高，时间间隔最好以任务的预估完成时间估算。
比如第一次连接到 redis 的时间消耗的比较长（连接池经常这样），那么第二次扫描 redis 自然有可能还没过期的。

如果是用 redis 做分布式单任务，给你一个简单的方案
1. 用 xxx+时间戳作为键名
2. 时间戳为固定值，比如你的 50ms 的间隔，那么时间戳是 00:00:00.050 、00:00:00.100 、00:00:00.150 等等。如果是 00:00:00.067 运行的任务，那么去除余数是 00:00:00.050 。
3. 用 setnx 就能完成检查+过期
4. 任务计时器的线程不要承担业务代码

orm 很适合写后台查询

微信恶心的地方：部分工作上要用但是又不保留、同步聊天记录