龙空技术网

微信红包高性能架构复杂度分析

南絮爸爸 1519

前言:

目前朋友们对“微信红包算法go”大概比较讲究,同学们都想要知道一些“微信红包算法go”的相关资讯。那么小编同时在网摘上网罗了一些关于“微信红包算法go””的相关资讯,希望看官们能喜欢,你们一起来学习一下吧!

红包复杂度总体分析

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

红包高性能复杂度分析

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

标签: #微信红包算法go