红包高性能复杂度分析
做性能分析，我们计算的都是按峰值来计算，上图是我们得出的一些数据。软系统的性能都是用峰值TPS/QPS来衡量的，其时间单位是秒。
红包高性能复杂度应对思路：
对照复杂度
进程模型：主从模型、生产者-消费者模型、管道模型…
网络模型：TCP/IP模型、五层模型、OSI模型…
缓存模型：应用程序缓存模型、数据库缓存模型、内存缓存模型…
红包高性能复杂度应对思路-发红包:
因为你不是新开发一个系统，那进程模型、网络模型、缓存模型基本都是跑在原有的框架之上，基本不要改，用springboot就用springboot。存储模型我的考虑点是红包的读写业务还是比较复杂的 不是一个简单的查询模型，所以暂时有B+树，集群方面：计算高性能 发红包是个简单的业务 任务分配就行了。存储方面，关系数据库的分片存储 一个数据库支持2.5万 还是比较吃力的。
发红包架构图：
上面是一个初步的架构 草稿纸也能画得出来。
抢红包
存储不用 Redis List 用数据库是否可以？
其实也是可以，性能要关注 ，Mysql的成本比较高 同等的条件范围下，一般来说数据库的服务器的成本要比负责运算的机器要高。
为啥 hash ？抢红包分配在一个机器，业务会简单 实现简单 不要分布式的消费
不过中间增加机器，hash的过程肯定会变。
看红包：
看红包架构= 抢红包架构
红包高性能方案 整体架构
红包整体架构图-单机房示意图：
高性能架构的成本优化思路：
优化方案-发红包拆分:这还是比较投机取巧的
【小结】
-
红包的复杂度主要体现在质量复杂度
-
每天1亿的请求量不一定是高性能
-
将发红包、拆红包分为不同的服务，可以提升性能
-
红包业务可以作为支付业务的功能，也可以按照独立业务来看
-
降本不只是主要靠提升单机处理性能
原文始发于微信公众号（二进制跳动）：微信红包高性能复杂度分析(思路型)
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/167463.html
