锐客网

  1. 首页 > 睿知 > it技术 > >

淘宝代码重构java 淘宝 代码( 二 )

IT技术版本


第一个上线的应用是数据魔方中的prom 。prom原先是基于redis构建的，因为数据量持续增大以及需求的变化，因此我们用hbase重构了它 的存储层 。准确的说prom更适合0.92版本的hbase，因为它不仅需要高速的在线读写，更需要count/group by等复杂应用 。但由于当时0.92版本尚未成熟，因此我们自己单独实现了coprocessor 。prom的数据导入是来源于云梯 ， 因此我们每天晚上花 半个小时将数据从云梯上写入hbase所在的hdfs，然后在web层做了一个client转发 。经过一个月的数据比对，确认了速度比之redis并未有 明显下降，以及数据的准确性 ， 因此得以顺利上线 。
第二个上线的应用是TimeTunnel，TimeTunnel是一个高效的、可靠的、可扩展的实时数据传输平台，广泛应用于实时日志收集、数据实 时监控、广告效果实时反馈、数据库实时同步等领域 。它与prom相比的特点是增加了在线写 。动态的数据增加使hbase上compact/balance /split/recovery等诸多特性受到了极大的挑战 。TT的写入量大约一天20TB，读的量约为此的1.5倍 ， 我们为此准备了20台 regionserver的集群，当然底层的hdfs是公用的 ， 数量更为庞大（下文会提到） 。每天TT会为不同的业务在hbase上建不同的表，然后往该 表上写入数据，即使我们将region的大小上限设为1GB，最大的几个业务也会达到数千个region这样的规模，可以说每一分钟都会有数次 split 。在TT的上线过程中，我们修复了hbase很多关于split方面的bug ， 有好几个commit到了hbase社区，同时也将社区一些最新 的patch打在了我们的版本上 。split相关的bug应该说是hbase中会导致数据丢失最大的风险之一 ， 这一点对于每个想使用hbase的开发者来 说必须牢记 。hbase由于采用了LSM-Tree模型，从架构原理上来说数据几乎没有丢失的可能，但是在实际使用中不小心谨慎就有丢失风险 。原因后面会 单独强调 。TT在预发过程中我们分别因为Meta表损坏以及split方面的bug曾经丢失过数据，因此也单独写了meta表恢复工具，确保今后不发生类 似问题(hbase-0.90.5以后的版本都增加了类似工具) 。另外，由于我们存放TT的机房并不稳定，发生过很多次宕机事故，甚至发生过假死现象 。因 此我们也着手修改了一些patch，以提高宕机恢复时间，以及增强了监控的强度 。
【淘宝代码重构java 淘宝 代码】CTU以及会员中心项目是两个对在线要求比较高的项目，在这两个项目中我们特别对hbase的慢响应问题进行了研究 。hbase的慢响应现在一般归 纳为四类原因：网络原因、gc问题、命中率以及client的反序列化问题 。我们现在对它们做了一些解决方案(后面会有介绍)，以更好地对慢响应有控制 力 。
和Facebook类似，我们也使用了hbase做为实时计算类项目的存储层 。目前对内部己经上线了部分实时项目，比如实时页面点击系 统，galaxy实时交易推荐以及直播间等内部项目，用户则是散布到公司内各部门的运营小二们 。与facebook的puma不同的是淘宝使用了多种方式 做实时计算层，比如galaxy是使用类似affa的actor模式处理交易数据，同时关联商品表等维度表计算排行(TopN)，而实时页面点击系统则是 基于twitter开源的storm进行开发，后台通过TT获取实时的日志数据 ， 计算流将中间结果以及动态维表持久化到hbase上，比如我们将 rowkey设计为url+userid，并读出实时的数据，从而实现实时计算各个维度上的uv 。
最后要特别提一下历史交易订单项目 。这个项目实际上也是一个重构项目，目的是从以前的solr+bdb的方案上迁移到hbase上来 。由于它关系到 己买到页面 ， 用户使用频率非常高，重要程度接近核心应用 ， 对数据丢失以及服务中断是零容忍 。它对compact做了优化，避免大数据量的compact在 服务时间内发生 。新增了定制的filter来实现分页查询 ， rowkey上对应用进行了巧妙的设计以避免了冗余数据的传输以及90%以上的读转化成了顺序 读 。目前该集群存储了超过百亿的订单数据以及数千亿的索引数据，线上故障率为0 。

推荐阅读


上一篇：微信关注公众号助力群，帮关注公众号的群

下一篇：excel框框中怎么打勾，excel如何框里打勾