前言:
目前朋友们对“微信红包算法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