HBase方案 | 基于Lindorm的互联网帐单解决方案

               

一.背景

无论是对于传统行业仍是对于互联网行业，交易订单数据的存储需求由来已久，好比笔者最初所处的民航业，其CRS系统（代理人机票售票系统）存储了旅客的订座记录；又如各种银行须要存储广大储户在其系统内的支取和存入的流水记录；再如电子商务/第三方支付平台，广大网民的网购、缴费、理财、充值等交易行为的记录也须要保存。
交易性质的数据每每有较强的事务需求，好比电商系统中交易数据的存储会有多张表，表与表之间的数据须要保证强一致性。基于这样的要求，CRS系统最初选择了专业性较强的Unisys大型机系统及其数据库；银行的选择则是你们较为熟悉的IBM DB2；而淘宝/支付宝这样的电子商务的领头羊，最初的选择则是Oracle，在Oracle时代每每是一个业务一套数据库，不一样业务作垂直隔离，其架构以下图所示：

如前所述，对于第三方支付场景，交易系统主要面向接单，操做以写入为主。可是，随着其业务场景的不断丰富，从最初只有网上购物，以后涌现出转帐、公共事业缴费、话费充值等等愈来愈多的场景，而这些系统因其业务特征的不一样，每每是相互垂直，相对独立的交易系统。这样一来，对于一个普通网民而言产生了一个朴素而基本的需求，有一个统一的帐单查询入口，毕竟普通老板姓的钱不是大风刮来的。所以，帐单系统应运而生。

二.互联网帐单系统的架构演进

互联网帐单系统，从诞生的第一天起附带了一些自然的属性。

• 只读性：帐单的数据来自于上游各个交易系统，经过可靠消息进行数据同步，提供统一的查询入口给最终用户。

• 高增加：互联网的一个很是典型的特征就是超乎想象的高速增加，特别是处于风口的猪，是真的会被吹起来的。

• 低成本：帐单系统不像交易系统，不直接产生经济效益，总有一种庶出的感受。所以，指望重金投入那是绝对不可能的。

• 高可用：帐单系统是面向客户，对交易系统的延伸，是客户对交易数据的查询入口，对C端客户而言，其实并存在交易系统和帐单系统的区分。所以，这两个系统的可用性要求是一致的。

• 多维度查询：对于C端用户而言，每每会从不一样角度对帐单进行分类、标记以及查看和过滤本身的帐单。

2.1一代架构

2.1.1 基于MySQL的分库分表

基于上述的特征，在IOE还处于统治地位的时代，支付帐单系统最初拥抱的并非交易系统使用的、成本高昂的Oracle数据库，而是开源世界里最流行的、基于PC服务器的MySQL数据库，而且由于规模的缘由，每每须要引入相对更加复杂的分表、分库方案，其架构以下图所示(图中省略了MySQL Slave集群及Master、Slave间的复制关系)：

然而，如前所述，业务的快速增加带来数据的极速膨胀，须要不断的增长分表、分库的数量，不然就会达到MySQL单实例的瓶颈，而拆分为更大规模的分表、分库的运维代价是极其巨大的。基于此缘由，帐单系统的存储演变到了下一代架构。

2.2 二代架构

上文描述到，随着业务的不断增加，因为MySQL自身容量的天花板，第一代架构面临的问题没法解决，单纯依赖MySQL的架构已经再也不是帐单业务的合适选择。
所以，不一样的用户作出了不一样的选择。

2.2.1 MySQL热数据+HBase全量的混布架构

作为架构演进的一种选择，有一部分用户的选择是仍然依赖MySQL，但会将经过消息系统过来的数据同时写入到MySQL的分表和HBase集群中的单表。MySQL作为主存储，承担“热”数据的读请求，而HBase作为备存储，仅承担历史数据的读请求。这种架构下MySQL仅须要保存业务定义的指定周期内的热数据，所以，在演变到该架构的初期，极大的缓解了数据增加带来的压力。
可是，随着时间的推移，业务的飞速发展，热数据的量不断变大，所以仍然面临继续作拆分的需求；并且须要天天起定时任务进行历史数据的删除，大规模的数据删除引发了集群负载的升高，对集群稳定性产生了严重的隐患；
另外一方面，业务形态也在发生变化，好比：出现了最典型的“双十一”，这样超级的业务大热点，这就迫使须要对MySQL作更细粒度的拆分，而且每一年大促前要大量扩容节点，大促后还原到原有规模，这对于存储系统提出了极致的弹性扩缩容需求，而这样的要求对于存储计算一体化的架构而言是很是大的挑战。
同时，双十一带来的不只仅是业务量上的一个巨大尖刺，也带来了一些其余的不稳定因素，好比：会随时奔出来一个大卖家，这样的大热点每每致使单个MySQL实例容量不足，在计算存储一体化的架构下，应对这样的问题老是显得有点力不从心。

2.2.2 基于Share Nothing架构的分布式关系型数据库

作为架构演进的另外一种选择，其余一部分用户则抛弃了MySQL，选择新的市面上比较流行的分布式关系型数据库。分布式关系型数据库经过其内置的数据分片的能力，很好的避免了业务增加、新业务场景(双十一)带来的分库、分表的需求；经过其自动化的扩容/缩容能力，相比MySQL架构下的运维成本也有大幅度的下降。
可是，这种架构下也面临着一些问题：

• 存储成本高

• 
  

  • 没法按需扩缩容：单台服务内的CPU、内存、磁盘资源的配比是固定的，在Share Nothing架构下，无论是计算仍是存储资源不足，都只能进行总体扩容，这样就致使了没必要要的资源投入，从而提升了运行成本。

• 
  

  • 冷热分离：在Share Nothing架构下，即使不考虑是否已经实现了冷热分离，在实践层面也会有一些问题。好比：帐单数据有永久保存的需求，意味着冷数据占比会愈来愈高，而机型是固定的，所以集群会由于冷存储不能知足需求，而进行扩容，从而致使没必要要的资源投入；或者采用非固定/非标准化机型，则意味着运维复杂度的提高。

• 
  

  • 性能问题：关系型数据库主要面向的业务场景是有强事务需求的交易、支付、帐务类业务，须要强事务保证，每每会致使部分操做的串行化，从而下降了性能。另外一方相关系型数据库不像NoSQL，须要通过SQL层的解析并生成执行计划后才能执行，这个过程也不可避免的产生了必定的资源开销，从而下降了性能。性能的降低意味着单机吞吐量的降低，进而须要更多的服务器资源的投入，即意味着成本的增长

• 弹性能力差
  存储计算一体的Share Nothing架构，致使扩容节点的过程须要伴随着数据的搬迁，从而致使节点扩容的代价和耗时都是比较大的，致使面对双十一这样的须要极致弹性扩缩容能力的场景，显得力不从心。更长的扩缩容时间意味着更长的资源保有周期，从而提高了大促运行成本

• 热点问题：

• 
  

  • 应急效率低：Share Nothing架构下，应对随时可能出现的热点问题也是很是低效的,致使有较高的稳定性风险。好比：双十一忽然涌现出来的一个大卖家，热点卖家和该节点的其余卖家共享服务器资源，因为历史数据的存在，并不能当即隔离识别出来的热点，而是须要等待历史数据同步完成后，才能切流到独立的空闲节点。这样的应急速度在双十一这样的大促下显然是很是低效，难以知足稳定性需求的。

• 
  

  • 存储不均衡：Share Nothing架构下，有热点帐号的状况下，数据量每每也会比较大，致使节点间数据量的不均衡，从而须要人工去干预对大帐号所在节点作拆分，致使运维成本上升。

2.3 三代架构

所以，势必须要有一种新的更完善的数据库产品来知足帐单场景的需求。
首先，咱们简单回顾一下1、二代架构下面临的最核心的业务痛点，也是三代架构下必需要着重面对而且解决的问题。

• 存储成本高

• 弹性能力差

• 热点问题

那么，市面上是否存在这样的一款数据库产品“刚好” 能解决帐单场景在1、二代架构下遇到的问题，同时又能很好的知足帐单系统对可用性，对多维度查询的要求？答案是确定的。Lindorm正是这样一个合适的数据库选型。

三.基于Lindorm的架构

Lindorm是诞生于大数据时代的一款NoSQL数据库，低成本解决海量大数据的高效存、取是根植于其体内的基因。Lindorm在阿里内部历经十年的技术积淀，目前是阿里内部使用最为普遍的、数据体量最大的核心数据库产品。这一切归功于Lindorm拥有众多的核心技术和功能特性。
那么，面向帐单场景的业务痛点，Lindorm有哪些重要的抓手呢？

3.1 低成本

对于帐单这样的海量数据场景，数据有着很是典型的访问特征，近期数据访问频率较高，请求的响应延迟要求也较高，随着时间的推移访问频率会逐步下降，甚至仅做为历史数据存在，而只有极少许的访问，但另外一方面业务要求数据永久保留的特性，致使其在线数据体量很是大。Lindorm的冷热分离和压缩优化则能够很是有效的解决这个问题。

3.1.1 冷热分离

Lindorm具有在单一个存储架构下的“一张表”内实现数据的冷热分离，系统会自动根据用户设置的冷热分界线，自动将表中的冷数据归档到冷存储中。在用户的访问方式上和普通表几乎没有任何差别，在查询的过程当中，用户只需配置查询Hint或者Time Range，系统根据条件自动地判断查询应该落在热数据区仍是冷数据区。对用户而言始终是一张表，对用户几乎作到彻底的透明。

3.1.2 压缩优化

存储成本最低的系统是没有数据须要存储的系统，但这点显然是不现实的，现实可行的方案是将须要存储的数据降到合理的最低点。
为了下降存储开销，Lindorm引入了一种新的无损压缩算法，旨在提供快速压缩，并实现高压缩比。它既不像LZMA和ZPAQ那样追求尽量高的压缩比，也不像LZ4那样追求极致的压缩速度。这种算法的压缩速度超过200MB/s, 解压速度超过400MB/s（实验室数据），很好的知足Lindorm对吞吐量的需求。经实际场景验证，新的压缩优化下，压缩比相对于LZO有很是显著的提升，存储节省能够达到50%～100%，对于存储型业务，这就意味着最高能够达到50%的成本减小。

3.2 极致弹性

互联网世界老是以超乎想象的速度在飞速增加。帐单的峰值读&写请求量、须要存储数据量会伴随着业务飞速的增加，每一年都会是上一年的翻倍甚至数倍，所以须要存储系统具有良好的扩展能力。
双十一这样的业务场景，则会瞬间带来数十倍甚至百倍的峰值读写量，为了知足这样的场景，就须要存储系统具有更加极致的弹性扩、缩容的能力。
如前所述，低成本解决海量大数据的高效存、取是根植于Lindorm体内的基因。所以，Lindorm自然就具有了良好的线性扩展能力，能够很好的支撑每秒亿级别请求，PB级数据量，并且在大数据量、高并发下仍然能提供稳定的毫秒级的平均响应。
Lindorm原生支持存储计算分离架构( 其架构以下图)，这样的架构设计使得集群扩容、缩容都变得很是的轻量，说简单一点就是“起个进程+数据分片balance”这点事，新节点接收业务请求并不须要等待历史数据的搬迁，而缩容刚恰好是逆向的过程。所以，对于Lindorm而言弹性扩缩容固然是分分钟搞定咯！

3.3 热点问题

3.3.1 高效热点响应

交易分为买家和卖家两个对手方，帐单数据也每每会按照这两个用户维度进行组织。从单个买家角度看每每交易量较低，不至于造成热点。可是卖家却多是一个大的焦点，特别是在双十一这样的大压力下，单个UID的交易量尖刺每每会更高。
热点对于任何一个存储系统而言都是灾难性的，但Lindorm自然的读写分离架构在应对热点方面会有更大的优点。
Lindorm分为存储和计算两层，LDserver负责数据分片的组织和读写访问，Lindorm Store负责文件的存储和访问。数据分片在不一样LDserver之间的移动并不须要考虑Lindorm Store层存储位置。所以，当读写出现热点时，Lindorm能够经过快速移动数据分片到空闲节点，便可秒级完成热点数据分片的隔离，达到提高抗热点的能力。

3.3.2 存储水位不均问题

如前所述，Lindorm采用存储计算分离的架构，数据按region进行分片，其大小在GB级别，一般指定为8G，16G，超过阈值会自动进行split，数据分片会自动在不一样节点间进行balance。所以，这样的架构设计使得Lindorm能够很好的保持不一样节点间数据量的均衡。从而很好的避免了Share Nothing架构下热点帐号带来的“没必要要”的运维工做。

3.4 其余必要特性

Lindorm的上述几个特性很好的解决了帐单系统在1、二代架构中难于解决的问题，可是帐单场景对存储系统基本要求：可用性、多维度查询，在三代架构下也是必需要知足的，不然就是顾此失彼，甚至得不偿失了。

3.4.1 高可用

Lindorm的表数据经过自动balance策略分散到集群中的多台服务器上，每个数据分片能够拥有1至N个副本，这N个副本拥有主、从两种角色，主从副本能够加载在不一样的Zone，从而保障集群的高可用和强一致。针对不一样的一致性模式，主从副本之间的数据同步和读写模式以下：

• 强一致模式：只有主副本提供读写，数据会异步回放到从副本,主副本所在节点故障，从副本晋升为主(晋升以前会保障数据同步完成，从副本拥有全部最新数据，总体过程由Master协调负责)

• 最终一致模式：主从副本都提供读写，数据会相互同步，保证副本之间的数据最终一致。
  

经过这样的高可用机制，Lindorm能够很好的保障帐单这样的对数据强一致性和可用性需求都很是高的业务。

3.4.2 多维度查询

为了解决业务基于非主键列的查询问题，Lindorm内置原生的全局二级索引功能，对于列较少且有固定查询模式的场景来讲，高性能二级索引方案可以完美解决此类问题，同时仍保持强大的吞吐与性能。

当面对更加复杂的查询，好比模糊查找、随机条件组合查询等等，二级索引方案会显得力不从心，这时候Lindorm搜索引擎LSearch就有其用武之地。LSearch是面向海量数据设计的分布式搜索引擎，兼容开源Solr标准接口，同时可无缝做为宽表、时序引擎的索引存储，加速检索查询。其总体架构与宽表引擎一致，基于数据自动分区+分区多副本+Lucene的结构设计，具有全文检索、聚合计算、复杂多维查询等能力，支持水平扩展、一写多读、跨机房容灾、TTL等，知足海量数据下的高效检索需求。

四.Lindorm核心能力概述

Lindorm经过全方位多角度的能力提高，充分知足了帐单场景的高可用、高吞吐、低延迟、低成本、多维度及可能的突发热点请求等等一系列的需求。
固然，Lindorm的能力还远不止于此，Lindorm具有了大数据背景下，面向海量数据的存储系统应该具有的一系列的能力：

• 是一款支持宽表、时序、搜索、文件的多模数据库

• 是一款基于存储计算分离架构的数据库，提供极致的计算、存储弹性伸缩能力，并将全新提供Serverless服务，实现按需即时弹性、按使用量付费的能力

• 是一款支持冷热分离、、追求更优压缩优化方案的极具性价比的数据库

• 是一款具有全局二级索引、多维检索、时序索引等功能的数据库

• 提供具有智能化服务能力的LDInsight工具，白屏化完成系统管理、数据访问及故障诊断

• 提供LTS(Lindorm Tunnel Service，原BDS)，支持简单易用的数据交换、处理、订阅等能力，知足用户的数据迁移、实时订阅、数湖转存、数仓回流、单元化多活、备份恢复等需求

五、帐单场景客户案例

第三方支付帐单

某国内领先的第三方支付平台，致力于提供“简单、安全、快速”的支付解决方案。自2014年第二季度开始成为当前全球最大的移动支付厂商。
自从2013年起，该第三方支付平台已经将其全量的在线交易、线下交易、缴费、转帐等等各种交易数据全量存储在Lindorm内，提供实时、在线查询，能够获取帐单详情以及经过各种筛选条件知足C端用户的帐单筛选需求。

收钱吧

隶属于上海喔噻互联网科技有限公司，是中国移动支付服务商领军者，致力于用网络和数据的力量服务线下实体商家。收钱吧不只为商家提供专业移动支付收款工具，同时也是为商家提供金融、广告、营销管理、供应链等多种服务的生意帮手。2014年12月，收钱吧正式上线，开创了中国移动支付市场“一站式收款”时代，并成功研发了“收钱吧扫码王”等全场景智能收款设备，产品得到多项国家专利。目前收钱吧服务超过330万商家，日服务3000万人次。
收钱吧使用Lindorm做为其订单解决方案，成功实现了：

• 全文索引方案，使得业务高性能实现高维度&随机组合场景下的订单搜索

• 数据压缩优化及集群内冷热分离，使得业务低成本实现数据永久保留

• 相比优化前的架构，成本降低77.42%

• 全托管、免运维及SLA保障，并有专家团队的免费技术支持，使客户能尽心尽力聚焦业务侧发展