前语
最近看了一篇关于qq场景规划，那么咱们在面试中经常会有出一道场景题给你规划，检测下你相关领域的经历以及考虑谨慎，本篇基于国民应用QQ怎么完成高可用的订阅推送系统 该文章创造，首要是用于对比技能计划不同，从而进步个人技能才能，还有考虑问题可进步的地方。
场景
分析
咱们捕捉下关键词，超大流量，咱们联想到很大的并发；其次是订阅场景，那么在用户巨大的状况下，这类数据的贮存也是存在一定的问题，比方说500w用户，每人订阅2条便是千万以上，并且还有不同活动；第三个点是相似推送消息，让我想到推送可靠性、推送的功率并且还要确保机器的稳定性，比方说一下子推了一堆东西，然后把机器挤爆了，那就要把你拉去祭天了，嘿嘿～
我的规划计划
- 存储量大，分为两种结构、扩容视点来谈
这儿的事务分两种，一种用户订阅活动数据，一种是一个活动多少用户订阅，可能需求有时遽然需求计算一场活动它参加的人数，假如只保存用户的，你还需求遍历很多数据；还有另一种场景是推送，也是需求去计算，还不如以空间换时间，提早保存起来。
数据结构，用户订阅能够用redis hash，相当一个map，像我的话最多参加个某农药是吧，活动订阅的话也能够用redis hash去保存，这块涉及到变更，这种数据结构也是支持的。为什么不必mysql呢，我的想法首要仍是考虑到数据量大了之后对功能的影响，当然你也能够分库分表解决。
至于扩容同样的道理，redis的内存也能够加，然后进行分片保存，比方说一个活动，大概1w人参加，分为10个key，依据用户id mod一下，每个key贮存1k数据，以此类推，来避免big key对功能的影响。
当然实际大部分仍是依赖mysql去完成，在中小厂没有这么大的用户系统，跟贮存量，以及对功能的要求相对比较低。
- 发送量大，便是推拉方式的博弈
咱们能够参阅mq规划，也是推拉方式比较经典的规划思路。比方说推送可靠性、推送的功能，那我这儿首要选用推的方式，我的考虑是拉取对服务端压力大，客户端频繁去请求或许守时请求，对服务器的压力都是巨大的。那么在推的方式下，服务端会累积很多的推送量，这儿需求行列来削峰填谷，作为一个缓冲区域
- 收取量大，这是电商比较经典的扣库存、红包场景
扣库存的话能够用redis detr，或许list lpush去完成高功能，红包的话能够提早拆分好，然后具体金额数这个涉及到算法，比方让每个人均匀一点，仍是说随机一点。
到这儿咱们的规划就完毕了，接下来看看咱们计划跟qq的有什么不同吧～
与实际计划不同
1、数据贮存方面，跟咱们设想的一致，便是短少了事务方创建活动数据贮存
2、推拉方式
怎么讲呢，这儿暴露了一个咱们的思想被传统mq影响了，由于mq归于实时消费的，至于实际推送场景，能够放到本地去守时提醒，这又让咱们学习到一种方法。这儿是一种合作的方法，相似nacos装备，一般是守时拉取，假如有变更的话，经过push的方式让客户端再拉取一次，确保数据的实时性。
3、推送可靠性，这儿是参阅mq的规划
4、是咱们短少的监控环节
这是正常的，由于咱们做项目的时分，一般先把项目做起来，不然搞什么飞机对不对，都没有商场没有用户，你就把后续扩展搞得很完全，这跟实际事物发展比较违背的。
咱们要监控什么呢？推送的量，推送成功率，用户触达状况，最后做优化。
埋点->上报->监控->优化，监控在里面起到数据依据、可视化的作用。
总结
在技能计划里面，咱们学到了能够提早拉取然后提醒的计划，假如推送的话确实不在线的状况，会丢失这部分数据，它不像服务端一样24小时在线，当然咱们能够经过短信来辅助提醒；其次是监控环节，这也给咱们一个启示，便是项目后面阶段是需求对数据计算、数据监控上去下功夫。
