阿里巴巴大数据实践｜实时技术篇大促挑战＆保障（四）

前言

大家好,我是ChinaManor,直译过来就是中国码农的意思,我希望自己能成为国家复兴道路的铺路人,大数据领域的耕耘者,平凡但不甘于平庸的人。

以上是实时技术篇的思维导图 ～
接下来几篇 manor将更新正在阅读的《阿里巴巴大数据实践》的第五章实时技术

大促是电商行业的狂欢节，在这期间，各个业务系统面临的峰值都 会达到最高点，每年大促的海量数据处理给实时计算的性能和保障提出 了很大的挑战。

大促特征

大促和日常比较，在数据量以及要求上有非常大的区别，日常不怎
么关注的点，在大促的时候会被放大，并且一天中的峰值特别明显，数
据量是其他时间点的几倍甚至数十倍，这对系统的抗压能力要求非常
高，不能因为洪流的到来而把系统压垮。

• 1 .毫秒级延时 大促期间，业务方和用户都会对实时数据非常关注，特别是在跨过
  零点的时候，第一个实时数字的跳动对业务方来说意义重大，预示着大 促狂欢节真正开始。其他的产品，例如全球媒体直播大屏，更是要求延
  时达到毫秒级。这种要求吞吐量和延时兼得的情况，必须要做一些有针 对性的优化工作才能满足要求。
  2 .洪峰明显
  大促就是全国乃至全世界的狂欢节，零点开售时的峰值陡峰是非常 明显的，一般是日常峰值的几十倍，这对数据处理链路的每个系统都是 巨大
  的挑战。因此，在大促前会进行多次全链路压测和预案梳理，确保 统能够承载住洪峰的冲击
  3. 高保障性 由于关注的人非常 ，只要出现数据延迟或者数据质量的问题，业 务方的反弹就比较大，并且会第 时间感知到数据异常。因此，在大促 般都要求高保障 性， 些特殊的情况甚至需要做到强保障。 对于强保障的数据，需要做多链路冗余（从来集、处理到数据服务
  个数据链路都需要做物理隔离）（见图 5.7 ）。
  当任何 条链路出现问 时，都能够 键切换到备链路，并且需要对业务方透明，让下游感知
  到有链路上的切换（由于各个链路计算的速度有 定的差异，会导致 数据在切换时出现短时间下跌的情况，使用方需要做指标大小的判断，
  避免指标下跌对用户造成困扰）。
  
  4. 公关特性 大促期间，数据及时对公众披露是一项重要的工作，这时候要求实 时计算的数据质量非常高。这里面涉及主键的过滤、去重的精准和口径的统一等一系列问题，只有把每一个环节都做好才能保障和离线的数据 一致。

大促是 场对数据计算的高吞吐量、低延时、高保障性、高准确性
的挑战。

大促保障

如何进行实时任务优化
大促前的优化工作在实时计算中显得尤为重要，如果吞吐量跟不上
的话，也就失去了实时的特性。吞吐量不佳原因非常多，有些眼系统资
源有关，有些眼实现方式有关 以下几点是实时任务优化中经常需要考
虑的要素。

1. ( 1 ）独占资源和共享资源的策略 在一台机器中，共享资源池可以被多个实时任务抢占，如果 个任 务在运行时
   以上的时间都需要去抢资源，这时候就需要考虑给它分 配更多的独占资源，避免抢不到 资源导致吞吐量急剧下降。
   

   (2 ）合理选择缓存机制，尽量降低读写库次数 内存读写性能是最好的，根据业务的特性选择不同的缓存机制，让
   最热和最可能使用的数据留在内存中，读写库次数降低后，吞吐量自 就上升了。 (3 ）计算单元合并，降低拓扑层级 拓扑结构层级越深
   性能越差，因为数据在每个节点间传输时， 部分是需要经过序列化和反序列化的，而这个过程非常消耗 CPU 和时间 (4
   ）内存对象共享，避免字符拷贝 在海量数据处理中，大部分对象都是以字符串形式存在的，在不同
   线程间合理共享对象，可以大幅降低字符拷贝带来的性能消耗，不过 注意不合理使用带来的内存溢出问题。 (5 ）在高吞吐量和低延时间取平衡
   高吞吐量和低延时这两个特性是一对矛盾体，当把多个读写库操作 或者 ACK 操作合并成一个时，可以大幅降低因为网络请求带来的消耗，
   不过也会导致延时高一些，在业务上衡量进行取舍。
   

2. 如何进行数据链路保障

时数据的处理链路非常长（数据同步→数据计算→数据存储→数
据服务），每一个环节出现问题，都会导致实时数据停止更新。实时计
算属于分布式计算的 种，而单个节点故障是常态的，这种情况在直播
大屏中表现特别明显，因为数据不再更新，所有的用户都会发现数据出
现了问题。因此，为了保障实时数据的可用性，需要对整条计算链路都
进行多链路搭建，做到多机房容灾，甚至异地容灾（见图 5.8 ）。

由于造成链路问题的情况比较多，并且一般不能在秒级定位到原
因，因 会通过工具 比对多条链路计算 的结果数据，当某条链路出现问
题时，它一定会比其他链路计算的值小 ，并且差异会越来越大。这时候
会一键切换到备链路，并且通过推送配置的形式让其秒级生效，所有的
接口调用会立刻切换到备链路，对直播大屏完全透明，并且用户也感知
不到故障的发生。
3. 如何进行压测
在大促备战中，会对实时链路进行多次压测，主要是模拟“双
的峰值情况，验证系统是否能够正常运行。压测都是在线上环境中进
的，分为数据压测和产品压测。
数据压测主要是蓄洪压测，就是把几个小时甚至几天的数据积累下
来，并在某个时刻全部放开，模拟“双 11 ”洪峰流量的情况，这里面
的数据是真实的。比如通过把实时作业的订阅数据点位调到几个小时或
者几天前，这时候每一批读到的数据都是最多的，对实时计算的压力也
最大。
产品压测还细分为产品本身压测和前端页面稳定性测试。
4. (1 ）产品本身压测 收集大屏服务端的所有读操作的 URL ，通过压测平台进行压测流 量回放，按照 QPS: 500
／秒的目标进行压测。在压测过程中不断地 迭代优化服务端的性能，提升大屏应用处理数据的性能。
(2 ）前端页面稳定性测试
将大屏页面在浏览器中打开，并进行 24 小时的前端页面稳定性 测试。监控大屏前端 JS 对客户端浏览器的内存、 CPU 等的消耗，检测
出前端 JS 内存泄漏等问题并修复，提升前端页面的稳定性。

总结

以上便是阿里巴巴大数据实践｜实时技术篇的全部内容了~

愿你读过之后有自己的收获,如果有收获不妨一键三连，我们下篇再见?·