您现在的位置是:首页 > 文章详情

关于亿级流量问题的思考

日期:2020-03-03点击:469

    下午做技术的朋友找我问了一个问题,回答之后觉得差点意思,重新考思考过后很有收获。

 

                                 

    题目是这样的:某大厂需要做一个调度中心作定时任务处理,日活亿级,那么如何保证消息触达的时效性(发送快,消费也要快)?或者精准触发,比如30分钟后订单超时触发超时任务?    “What  亿级流量?”我第一反应就懵了:“卧槽,这么大流量,从来没遇见过!”然后就想着怎么样才能提高系统的高并发高性能。常见的比如(大规模集群的情况下):

  1. 通过异步+任务拆解成批次,而后根据业务属性按是否可以并行做分组,用多机多线程并行并发去处理;
  2. 通过消息中间件,比如Rocketmq、Kafka来保证高吞吐低延时,消息扭转快;
    • 消费端做NIO多进程多线程的模式,多进程监听同一端口(Linux内核2.6以上已经能够处理惊群问题)接受消息、单进程多线程(线程池)处理消息、多线程(线程队列)派发消息;
    • 消息推送时需要做频率控制,比如限流,不然消费端可能受不了,保证不了可用性;
  3. 秒级触达意味网络IO上可能需要做“最优路径”解。举例来说,集群环境中我们如何保证高并发的性能呢?一群机器上要有一个分配器(也是集群的或者主备架构,以满足可用性)做负载均衡。那么回到这个问题上,意味着分配器要分配的足够快,主要压力体现在负载算法和连接管理上。比如负载算法要动态的,需要实时采集或各机器上子系统主动上报各连接的网络速率、负载指标,甚至子系统的TPS+QPS+并发数,分配器根据指标数据与它自己的规则模式匹配寻找最优路径解。
    • 连接管理上,肯定要选择长链接的推送通道,短连接耗资源且保证不了时效性;
  4. 对调度中心来说,发送的消息基本都为小包。那么,为了加快网络解析速度、不占用整个链路过多的耗时,可以做一些优化。比如:
    • 在四层TCP协议中启用Nagle算法(No_Delay选项)加快小包传输速度;
    • 在七层协议头添加校验和、四层协议头添加目标地址来减轻拆包、黏包的计算耗时;
    • 定制化或使用高性能的序列化协议,比如Thrift;

    但其实仔细一想,这无非就是堆砌一堆高性能组件,妄图解决亿级流量架构下的高性能问题。而且,后来找同事聊了一下,即使这样也支撑不了亿级这么大的数据量。

    那么,我们的思路真的对了吗?首先,我们真的弄清楚事实的本质了吗:

  • 这个业务到底是什么样场景?
  • 这个亿级流量到底是多少?1亿,10亿?
  • 消息到底要多久发完、多久消费完?1秒,几十秒,10分钟?

    让我们重新考虑一下这个问题:

  1. 首先,大的方向肯定集群+消息队列肯定是要的,而后根据业务场景区分生产服务器集群->消息队列->消费服务器集群也是必须的;

  2. 其次,更进一步,将消息组装和消息推送解耦来做,用多机多线程来加速处理速度;

    但如果放到亿级流量这么大体量的背景下,如果要保证消息触达的效率,就必须要弄清业务场景,比如接收这个消息要干什么,什么样的用户,什么运营模式等等;比如有些消息并不重要,用户接不接收都无所谓的;比如有些消息用户比较分散,需要分发到用户所在的同城机房;比如有些消息任务计算量大,需要在业务层解耦耗时高的操作,甚至做临前扩容,等峰值过后再撤回私有云的。这方面是要做区分的。一句话:脱离场景谈技术架构的,都是耍流氓!
    另外,如果仔细分析题目中“亿级流量”这个字眼的话,其实也很模糊。即使如京东快递、菜鸟物流这样大规模、高频次、时效要求(国内物流次日达的速率承诺)的业务场景,亿级日活,但这也跟10秒触发1亿条消息不是一回事。要知道日活亿级用户,拿1亿来算的话,每天有86400秒,平均下来TPS才1200,按照互联网业务的规律,峰值约等于均值3倍,也就不到4000。而且,一般情况下生成消息和消费消息都有业务逻辑处理,就算100秒消费完1亿消息,一秒钟的TPS就是100万(天猫双十一也就20万TPS),路由器才可能达到这个水平!即使消息队列也撑不住这么大的TPS,单机每秒能处理1000就很厉害了,而你要准备1000台这样的机器?

    事物都有极限,一定要做到怎么办呢?提前做或事后做。关键点在于,要有“计划性”。举个栗子:阿里双十一或腾讯春节红包,都是提前计算好业务的业务特征和运营属性,在预处理阶段就把任务拆分成批次,待峰值来临前这些任务就已经在用户的就近机房,等在哪儿了,就等用户触发。微信春节红包发红包时的倒计时,微信群红包发红包之前也有个确认操作,之所以这么做,其实就是为了提前将人(微信群)圈好。

    

                                

    所以一通分析下来,你可能也发现了,这可能就是个伪需求,没业务没需求,就一个亿级流量就把我们给吼住了。总结下来有两点经验:

  • 第一,像我们现在在面试的时候,往往一上来就这种千万级、亿级这样的问题,平常根本很难看得到的!没信心、没经验,一下子就自乱阵脚了,其实没必要。
    • 不要一碰到这种题目就想的很复杂,越来越复杂,但可能等到我们详细沟通下来,情况也许并不是那样;
  • 第二,学会识别复杂性,比如题目中高性能这个复杂性,但光看到了这个复杂性不行,你还要抓住它、去分析它具体体现在哪里。即:先定性后定量分析问题的能力。
    • 更进一步,要有指标和判断的基准线,这需要经验和积累。

 

原文链接:https://my.oschina.net/duofuge/blog/3187255
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章