红包复杂度总体分析
图片
红包业务应该属于质量复杂度
图片
红包高性能复杂度分析
图片
做性能分析，我们计算的都是按峰值来计算，上图是我们得出的一些数据。软件系统的性能都是用峰值TPS/QPS来衡量的，其时间单位是秒。
红包高性能复杂度应对思路：
对照复杂度
图片
进程模型：主从模型、生产者-消费者模型、管道模型...
网络模型：TCP/IP模型、五层模型、OSI模型...
缓存模型：应用程序缓存模型、数据库缓存模型、内存缓存模型...
红包高性能复杂度应对思路-发红包:
图片
因为你不是新开发一个系统，那进程模型、网络模型、缓存模型基本都是跑在原有的框架之上，基本不要改，用springboot就用springboot。
存储模型考虑点是红包的读写业务还是比较复杂的，不是一个简单的查询模型，所以暂时用B+树，B+树的高度保持平衡，使查找操作效率高，在插入和删除操作时性能相对稳定，支持范围查询，因为它的叶子节点有序排列
集群方面：计算高性能 发红包是个简单的业务，任务分配就行了。存储方面，关系数据库的分片存储 一个数据库支持2.5万个红包， 还是比较吃力的。
发红包架构图：
图片
上面是一个初步的架构 草稿纸也能画得出来。
看红包
图片
存储不用 Redis List 用数据库是否可以？其实也是可以，性能要关注 ，Mysql的成本比较高，同等的条件范围下，一般来说数据库的服务器的成本要比负责运算的机器要高。
为啥 hash ？抢红包分配在一个机器，业务会简单，实现简单不要分布式的消费
不过中间增加机器，hash的过程肯定会变。
看红包：
图片
看红包架构= 抢红包架构
图片
红包高性能方案 整体架构
图片
红包整体架构图-单机房示意图：
图片
红包高性能方案 - 更高一级的架构决策
图片
高性能架构的成本优化思路：
图片
假设现在红包业务总共部署了1000台服务器，老板觉得运营成本太高，希望能够节省一些成本。
优化：
1. 服务器改为 Go 实现？
2. 发红包的时候拆分？
3. 红包业务和其它业务共用服务器？
创新:
1. 开发红包数据库？
2. 弹性扩容/缩容？
红包架构 - 全部用数据库存储
图片
其中的变化是：去掉了RedisCluster
优化方案-发红包拆分:这还是比较投机取巧的
图片
【小结】
- 红包的复杂度主要体现在质量复杂度
- 每天1亿的请求量不一定是高性能
- 将发红包、拆红包分为不同的服务，可以提升性能
- 红包业务可以作为支付业务的功能，也可以按照独立业务来看
- 降本不只是主要靠提升单机处理性能
