用 golang 实现了一个单机百万的系统， 可以支撑微信 100 亿红包那个强度的压力，欢迎 github 加星

[firefox12]

这里的编辑器不太好用，所以用图片传的

项目: https://github.com/xiaojiaqi/10billionhongbaos

文字 wiki: https://github.com/xiaojiaqi/10billionhongbaos/wiki/%E6%89%9B%E4%BD%8F100%E4%BA%BF%E6%AC%A1%E8%AF%B7%E6%B1%82%EF%BC%9F%E6%88%91%E4%BB%AC%E6%9D%A5%E8%AF%95%E4%B8%80%E8%AF%95

[yanyuan2046]

点赞

[loading]

start 先点再看。

[maja]

然并卵

给您加上个“牛逼”的“有情怀”的产品经理。

[wdlth]

领导看了非常感动，把买负载均衡设备的预算给砍了……

[ovear]

配合腾讯的一起看

5 天 2 亿活跃用户， 2017QQ “ LBS+AR ”天降红包活动后台揭密
http://wetest.qq.com/lab/view/286.html

[eimsteim]

LZ 无疑是牛逼的，我想请教下 LZ 的性能测试工具是用的什么？

[ljcarsenal]

厉害

[firefox12]

@eimsteim 性能测试分为 外部和内部，外部靠 ethtool 监控网络流量， 其他的还有 top dstat 这样的性能监控， 内部靠原子计数器 对很多节点计数，在监控节点汇总

[janxin]

文章覆盖知识点挺全的，点个赞

[tracymcladdy]

先点赞，明天看。

[danielmiao]

简单的看了一下说明，没有太细致的研究，但是貌似缺少了持久化的步骤，纯内存操作确实可以很快，但是对于涉及到交易，支付的系统，如何保证整个流程的完整性和数据的可靠性?

[firefox12]

@danielmiao 如果你看了微信的文章就知道，支付也不是在微信接入服务器做的。持久化 交易是靠支付保证的。支付每秒 5 万笔 大概是 双 11 的一半。对于接入，要做的就是记录一个日志就可以了，交易的一致性是靠微信支付去做的。

[danielmiao]

@firefox12 对，你说的没错。全异步队列的吞吐确实可以很高，但是大并发下消息的可靠性可能会有问题，再者既然您这边有红包生成，必然有预算管理，一个系统不可能凭空无限制生成钱出来。然而有预算的扣减必然有扣减的持久化，最后才到微信支付的交易（划账）的过程，一个预算的扣减，一个预算消费纪录的持久化这 2 个 IO 操作，必然是整个系统的瓶颈所在，所以个人感觉抛开瓶颈，测试的无非是 MQ 的性能和大并发下的内存管理问题，对于一个“系统”来说，可能差距还是有点的

[firefox12]

@danielmiao 这是由业务决定的，生成红包只需要 在生成时，持久化就可以，其次可以在发出去的时候 持久化就可以。这 2 部分的技术核心在支付，一次扣款，一次付款，当然扣款可以统一扣除。付款才需要多次执行。所以基本可以退化成 1 次。在接入服务器里 只有一次记录，关键是支付模块的记录。但是可以简单的 3 次写日志。慢慢到账，每秒 5 万笔的数目，从记录日志的角度看，并不大，交易本身的安全，交易才是关键。 我这个模拟主要在 2.3 万笔的摇操作。微信的文章也主要写接入，业务处理时直接队列化以后 发到微信支付去的。

[firefox12]

v 友真是给力 已经 360 星了。 谢谢支持