红包复杂度总体分析

图片

红包业务应该属于质量复杂度

图片

红包高性能复杂度分析

图片

做性能分析，我们计算的都是按峰值来计算，上图是我们得出的一些数据。软件系统的性能都是用峰值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. 红包的复杂度主要体现在质量复杂度
2. 每天1亿的请求量不一定是高性能
3. 将发红包、拆红包分为不同的服务，可以提升性能
4. 红包业务可以作为支付业务的功能，也可以按照独立业务来看
5. 降本不只是主要靠提升单机处理性能