本次阅读文章为：蚂蚁金服11.11：支付宝和蚂蚁花呗的技术架构及实践
文章地址：https://mp.weixin.qq.com/s?__biz=MzAxNjAzMTQyMA==&mid=2648476063&idx=1&sn=882fb8584b82107d5af191af5b805d0e&chksm=83d3224cb4a4ab5a72e04dbaa6c6621cc866ab913bb7abb1aa8e6f7860e128501ca1a3c26d4a&scene=21#wechat_redirect
众所周知淘宝网的数据量是非常大的，那么，这些数据的存储就是一个很艰难的问题，因为大量的数据写入和读取相对于传统的关系型数据库相对来说是比较难的。而淘宝网为了解决这个问题，采用了新型的架构，在一定的时间段内数据是只读的。这个架构分为五层，分别是数据源、计算层、存储层、查询层和产品层。位于架构顶端的是我们的数据来源层，这里有淘宝主站的用户、店铺、商品和交易等数据库，还有用户的浏览、搜索等行为日志等。在数据源层实时产生的数据，通过淘宝主研发的数据传输组件DataX、DbSync和Timetunnel准实时地传输到一个有1500个节点的Hadoop集群上，这个集群我们称之为“云梯”，是计算层的主要组成部分“银河”也是一个分布式系统，它接收来自TimeTunnel的实时消息，在内存中做实时计算，并把计算结果在尽可能短的时间内刷新到NoSQL存储设备中，供前端产品调用。
在数据魔方中，仍然以关系型数据库为主题，设计了分布式MySQL集群的查询代理层——MyFOX，使得分区对前端应用透明。关系型数据库的便利性在面对全属性选择器的问题上，无法解决。所以便出现了Nosql，以Hbase为底层数据库，建立的Prom，这样的设计思路是要充分利用各个节点的并行计算能力，并且避免大量明细数据的网络传输开销。MyFOX和Prom为数据产品的不同需求提供了数据存储和底层查询的解决方案，但随之而来的问题是，各种异构的存储模块给前端产品的使用带来了很大的挑战。
除了起到隔离前后端以及异构“表”之间的数据整合的作用之外，glider的另外一个不容忽视的作用便是缓存管理。数据产品中的数据是只读的，这是利用缓存来提高性能的理论基础。但是缓存也存在失效的时候，缓存系统不得不考虑的另一个问题是缓存穿透与失效时的雪崩效应。缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个存在的数据每次请求都要到存储层去查询，失去了缓存的意义。而缓存的雪崩效应影响更是巨大，但是目前并没有找到好的解决方案，在数据魔方中，我们设计的缓存过期机制理论上能够将各个客户端的数据失效时间均 匀地分布在时间轴上，一定程度上能够避免缓存同时失效带来的雪崩效应。
数据魔方目前已经能够提供压缩前80TB的数据存储空间，数据中间层glider支持每天4000万的查询请求，平均响应时间在28毫秒，足以满足未来一段时间内的业务增长需求。
所以，这种架构方式值得我们借鉴学习。