用 golang 实现了一个单机百万的系统， 可以支撑微信 100 亿红包那个强度的压力，欢迎 github 加星
firefox12 2017-02-19 11:06:57 +08:00 11318 次点击这是一个创建于 3206 天前的主题，其中的信息可能已经有所发展或是发生改变。
 | 1 yanyuan2046 2017-02-19 11:53:40 +08:00 点赞 |
 | 2 loading 2017-02-19 11:55:04 +08:00 start 先点再看。 |
 | 3 maja 2017-02-19 11:59:27 +08:00 然并卵 给您加上个“牛逼”的“有情怀”的产品经理。 |
 | 4 wdlth 2017-02-19 12:10:34 +08:00 领导看了非常感动，把买负载均衡设备的预算给砍了…… |
 | 5 ovear 2017-02-19 12:41:40 +08:00 |
 | 6 eimsteim 2017-02-19 13:17:24 +08:00 LZ 无疑是牛逼的，我想请教下 LZ 的性能测试工具是用的什么？ |
 | 7 ljcarsenal 2017-02-19 15:06:02 +08:00 via Android 厉害 |
 | 8 firefox12 OP @eimsteim 性能测试分为 外部和内部，外部靠 ethtool 监控网络流量， 其他的还有 top dstat 这样的性能监控， 内部靠原子计数器 对很多节点计数，在监控节点汇总 |
 | 9 janxin 2017-02-19 22:51:41 +08:00 文章覆盖知识点挺全的，点个赞 |
 | 10 tracymcladdy 2017-02-19 23:49:13 +08:00 via Android 先点赞，明天看。 |
 | 11 danielmiao 2017-02-20 10:23:13 +08:00 简单的看了一下说明，没有太细致的研究，但是貌似缺少了持久化的步骤，纯内存操作确实可以很快，但是对于涉及到交易，支付的系统，如何保证整个流程的完整性和数据的可靠性? |
| 12 firefox12 OP @danielmiao 如果你看了微信的文章就知道，支付也不是在微信接入服务器做的。持久化 交易是靠支付保证的。支付每秒 5 万笔 大概是 双 11 的一半。对于接入，要做的就是记录一个日志就可以了，交易的一致性是靠微信支付去做的。 |
| 13 danielmiao 2017-02-20 11:03:09 +08:00 @firefox12 对，你说的没错。全异步队列的吞吐确实可以很高，但是大并发下消息的可靠性可能会有问题，再者既然您这边有红包生成，必然有预算管理，一个系统不可能凭空无限制生成钱出来。然而有预算的扣减必然有扣减的持久化，最后才到微信支付的交易（划账）的过程，一个预算的扣减，一个预算消费纪录的持久化这 2 个 IO 操作，必然是整个系统的瓶颈所在，所以个人感觉抛开瓶颈，测试的无非是 MQ 的性能和大并发下的内存管理问题，对于一个“系统”来说，可能差距还是有点的 |
| 14 firefox12 OP @danielmiao 这是由业务决定的，生成红包只需要 在生成时，持久化就可以，其次可以在发出去的时候 持久化就可以。这 2 部分的技术核心在支付，一次扣款，一次付款，当然扣款可以统一扣除。付款才需要多次执行。所以基本可以退化成 1 次。在接入服务器里 只有一次记录，关键是支付模块的记录。但是可以简单的 3 次写日志。慢慢到账，每秒 5 万笔的数目，从记录日志的角度看，并不大，交易本身的安全，交易才是关键。 我这个模拟主要在 2.3 万笔的摇操作。微信的文章也主要写接入，业务处理时直接队列化以后 发到微信支付去的。 |
| 15 firefox12 OP v 友真是给力 已经 360 星了。 谢谢支持 |
Select Language