1.应用场景
| 主要用于学习，分析，借鉴 微信红包高并发架构设计 方案，进行技术储备，升级内在技术能力，提升架构设计功力，以后能高效进行架构设计。 |
2.学习/操作
| |
3.问题/补充
1. 网友评论肖一林 有三个基本动作:发红包，抢红包，拆红包。 发红包就是在数据库插一条红包库存数据， 抢红包就是查询红包库存数据， 拆红包就是插入一条秒杀流水并更新库存数据。 有三个难点: 一是海量的并发，二是资金安全，三是良好的用户体验。 资金安全决定了交易只能直接建立在数据库上，不能建立在缓存上。 良好的用户体验就是要求不能出现不公平的现象，保证先抢先得，先抢的不能失败。 解决方案是:
2. 网友-孙振超 负载均衡算法一共十来种之多，但经过抽取共性归纳之后就变成了4类，不仅容易记忆，即使以后再新增加其他的算法，也不外乎是进行了丰富，种类并没有什么变化，归纳为4类之后遇到类似的问题也可以用这样的方式去予以解决，从中也可以看到高手不只是机械性的记忆，而是带着思考去看待问题。 具体到微信红包的算法选择上，由于并发量特别高，需要有一个简单高效的算法，因而性能优先类算法可以不做考虑。 对于微信这种级别的机房，其容器化技术必然是炉火纯青，每一台vm的配置是可以完全相同的，因而也就无需采用负载均衡类算法和权重轮询算法，剩下来的就是hash类算法和简单轮询算法。 对于红包业务，最主要的操作是发红包和抢红包：不管是发个人红包还是发群红包整体业务相差不大，可以采用简单轮询算法，到任何一台服务器均可。但抢个人红包和抢群红包是不同的，抢群红包是有先后顺序，当有多个人抢同一个群红包时最好是由同一个服务器进行处理，这台服务器在收到抢红包的请求后将请求放到一个队列中，而后按照先进先出的方式进行消费，可以保证先到的人能抢到红包，后到的人后抢到红包。因而对于抢红包业务最好按照红包id进行hash负载。 如果是只选择一个负载算法的话，就是hash负载，发红包按照userid进行hash负载，抢红包按照红包id进行hash负载
3. 网友-Tom看到评论说按红包id hash，上亿人抢同一个新年红包，应该只有一个红包id 吧？
4. 网友-赵正 Allen发红包业务应该以红包的生命周期为思考的出发点。 主要经历：发，抢，查询，回收（没抢完，返回给发红包的用户）。 如果按这些细颗粒来看，抢，查询红包的并发要求最高，发红包次之，回收最低。 首先，发红包使用加权轮询，简单适用，成功后返回红包ID给客户端。 其次，抢红包，查询红包都带着ID给服务端，根据ID计算HASH，再利用一致性hash算法，找到最近的一个结点提供服务。 最后，回收应该由服务端定时触发，可以同样按抢红包处理。
|
4.参考
后续补充
...
扫一扫
4897
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
