Prefacio
En 2011, los dos grandes dioses Bi Xuan y Zhuzhuang introdujeron HBase en el sistema de tecnología de Alibaba. En 2014, el testigo se transfirió a Tianwu, el primer participante de HBase en el distrito East 8. A lo largo de los años, han cooperado con Taobao, Want Want, Cainiao, Alipay, Gaode y Dawenyu. Casi todos los socios de BU, como Alimama y Alimama, han trabajado de la mano para respaldar negocios centrales como la pantalla grande Double Eleven, la facturación de Alipay, el control de riesgos de Alipay y los detalles logísticos. En Double Eleven en 2018, HBase procesó 2,4 billones de filas de solicitudes a lo largo del día y el rendimiento de un solo clúster alcanzó decenas de millones. De un bebé a un joven, Ali HBase se ha caído muchas veces e incluso se ha roto la sangre Hemos crecido afortunadamente bajo la confianza de nuestros clientes, y estamos agradecidos. Desde 2017, Alibaba HBase se moverá hacia la nube pública. Hemos planeado proporcionar gradualmente la tecnología interna de alta disponibilidad de Alibaba a clientes externos. Actualmente, hemos lanzado la principal y la de respaldo en la misma ciudad y servirá como una plataforma básica para nuestro posterior desarrollo de capacidad de alta disponibilidad. Este artículo revisa el desarrollo de Alibaba HBase en términos de alta disponibilidad en cuatro partes: grupos grandes, MTTF y MTTR, tolerancia a desastres y experiencia final. Espero que pueda traerle algo de resonancia y pensamiento. Bienvenido a usar Alibaba Cloud HBase Serverless para abrir una nueva era de aprendizaje y pruebas de big data
Clúster grande
Un negocio y un clúster son fáciles al principio, pero a medida que aumenta el negocio, aumentará la carga de operación y mantenimiento y, lo que es más importante, es imposible utilizar los recursos de manera eficaz. En primer lugar, cada clúster debe tener los tres roles de Zookeeper, Master y NameNode, que consumen 3 máquinas de forma fija. En segundo lugar, algunas empresas se centran en la informática y la luz en el almacenamiento, y algunas empresas se centran en el almacenamiento y el cálculo de la luz. El modelo de separación no puede cortar picos y llenar valles. Por lo tanto, desde 2013, Ali HBase se ha trasladado a un modelo de clúster grande, con una escala de nodo de un solo clúster que llega a más de 700.
El aislamiento es un problema clave para los grandes clústeres. Es una capacidad muy importante garantizar que el tráfico anormal del servicio A no afecte al servicio B; de lo contrario, los usuarios pueden rechazar el modo de clúster grande. Ali HBase introdujo el concepto de agrupación "grupo", y sus ideas centrales son: almacenamiento compartido, computación aislada
Como se muestra en la figura anterior, un clúster se divide en varios grupos. Un grupo contiene al menos un servidor. Un servidor solo puede pertenecer a un grupo a la vez, pero los servidores pueden transferir entre grupos, es decir, el grupo en sí se puede expandir y encoger. Una mesa solo se puede implementar en un grupo y la mesa se puede transferir a otros grupos. Se puede ver que el RegionServer donde la tabla T1 lee y escribe está completamente aislado del RegionServer donde la tabla T2 lee y escribe. Por lo tanto, la CPU y la memoria están físicamente aisladas, pero el sistema de archivos HDFS usado por la capa inferior es compartido. , por lo que se pueden compartir varios servicios en un gran grupo de almacenamiento para mejorar por completo la utilización del almacenamiento. La comunidad de código abierto presentó RegionServerGroup en la versión HBase2.0.
El impacto de los discos defectuosos en el almacenamiento compartido: debido a las características del mecanismo HDFS, se seleccionarán aleatoriamente 3 nodos como canalización para la escritura de cada bloque. Si una máquina tiene un disco defectuoso, el disco defectuoso puede aparecer en varias canalizaciones. en este caso, un solo punto de falla causa fluctuación global. En la escena real, un disco está roto y docenas de clientes te envían mensajes y te llaman al mismo tiempo. Especialmente si los discos lentos y los discos defectuosos no se procesan a tiempo, eventualmente pueden causar un bloqueo de escritura. Ali HBase actualmente tiene una escala de más de 10,000 máquinas, y hay alrededor de 22 problemas de daños en el disco cada semana. Hemos hecho dos cosas para resolver este problema: la primera es acortar el tiempo de impacto, monitorear y alertar los discos lentos y defectuosos, y proporcionar una plataforma de procesamiento automatizada. El segundo es evitar el impacto de un solo punto de disco defectuoso en el sistema en el software. Al escribir HDFS, escriba tres copias al mismo tiempo. Siempre que dos copias sean correctas, se considerará correcto, y si la tercera copia se agota, será abandonado. Además, si el sistema encuentra que el WAL está escrito de manera anormal (el número de copias es menor a 3), generará automáticamente un nuevo archivo de registro (vuelva a seleccionar la canalización para evitar píxeles defectuosos). Finalmente, el propio HDFS también tiene la capacidad de identificar discos defectuosos y eliminarlos automáticamente en versiones altas.
El impacto de la conexión del cliente en Zookeeper: el acceso del cliente a hbase establecerá una conexión larga con Zookeeper, y el RegionServer de HBase también establecerá una conexión larga con Zookeeper. Un clúster grande significa una gran cantidad de negocios y una gran cantidad de conexiones de clientes. En circunstancias anormales, demasiadas conexiones de clientes afectarán los latidos de RegionServer y Zookeeper y causarán tiempo de inactividad. Nuestra respuesta aquí es, en primer lugar, limitar el número de enlaces para una única IP y, en segundo lugar, proporcionar una solución para separar los enlaces de cliente y servidor HBASE-20159
MTTF y MTTR
La estabilidad es la línea de vida. Con el desarrollo del negocio de Alibaba, HBase amplía gradualmente su soporte para escenarios en línea, y los requisitos de estabilidad son cada vez más altos cada año. Los indicadores comunes para medir la confiabilidad del sistema son MTTF (tiempo medio de falla) y MTTR (tiempo medio de recuperación)
MTTF （tiempo medio de falla）
Las fuentes de fallas del sistema son:
Falla de hardware, como disco defectuoso, tarjeta de red dañada, tiempo de inactividad de la máquina, etc.
Defecto propio, generalmente se refiere al propio error del programa o al cuello de botella de rendimiento
Fallo de operación y mantenimiento, falla debido a un funcionamiento irrazonable
Sobrecarga del servicio, puntos calientes repentinos, objetos grandes y solicitudes para filtrar grandes cantidades de datos
La dependencia falla y los componentes HDFS y Zookeeper dependientes no están disponibles, lo que hace que se cierre el proceso de HBase
Permítanme presentarles varios problemas representativos encontrados por Alibaba Cloud HBase en términos de estabilidad: (Nota: los problemas de los discos lentos y los discos defectuosos se han tratado en la sección sobre clústeres grandes, por lo que no los repetiré aquí)
La FGC periódica hace que el proceso se cierre
在支持菜鸟物流详情业务的时候，我们发现机器大概每隔两个月就会abort一次，因为内存碎片化问题导致Promotion Fail，进而引发FGC。由于我们使用的内存规格比较大，所以一次FGC的停顿时间超过了与Zookeeper的心跳，导致ZK session expired，HBase进程自杀。我们定位问题是由于BlockCache引起的，由于编码压缩的存在，内存中的block大小是不一致的，缓存的换入换出行为会逐步的切割内存为非常小的碎片。我们开发了BucketCache，很好的解决了内存碎片化的问题，然后进一步发展了SharedBucketCache，使得从BlockCache里面反序列化出来的对象可以被共享复用，减少运行时对象的创建，从而彻底的解决了FGC的问题。
写入HDFS失败导致进程退出
HBase依赖俩大外部组件，Zookeeper和HDFS。Zookeeper从架构设计上就是高可用的，HDFS也支持HA的部署模式。当我们假设一个组件是可靠的，然后基于这个假设去写代码，就会产生隐患。因为这个“可靠的”组件会失效，HBase在处理这种异常时非常暴力，立即执行自杀（因为发生了不可能的事情），寄希望于通过Failover来转移恢复。有时HDFS可能只是暂时的不可用，比如部分Block没有上报而进入保护模式，短暂的网络抖动等，如果HBase因此大面积重启，会把本来10分钟的影响扩大到小时级别。我们在这个问题上的方案是优化异常处理，对于可以规避的问题直接处理掉，对于无法规避的异常进行重试&等待。
并发大查询导致机器停摆
HBase的大查询，通常指那些带有Filter的Scan，在RegionServer端读取和过滤大量的数据块。如果读取的数据经常不在缓存，则很容易造成IO过载；如果读取的数据大多在缓存中，则很容易因为解压、序列化等操作造成CPU过载；总之当有几十个这样的大请求并发的在服务器端执行时，服务器load会迅速飙升，系统响应变慢甚至表现的像卡住了。这里我们研发了大请求的监控和限制，当一个请求消耗资源超过一定阈值就会被标记为大请求，日志会记录。一个服务器允许的并发大请求存在上限，如果超过这个上限，后来的大请求就会被限速。如果一个请求在服务器上运行了很久都没有结束，但客户端已经判断超时，那么系统会主动中断掉这个大请求。该功能的上线解决了支付宝账单系统因为热点查询而导致的性能抖动问题。
大分区Split缓慢
在线上我们偶尔会遇到某个分区的数量在几十GB到几个TB，一般都是由于分区不合理，然后又在短时间内灌入了大量的数据。这种分区不但数据量大，还经常文件数量超级多，当有读落在这个分区时，一定会是一个大请求，如果不及时分裂成更小的分区就会造成严重影响。这个分裂的过程非常慢，HBase只能从1个分区分裂为2个分区，并且要等待执行一轮Compaction才能进行下一轮分裂。假设分区大小1TB，那么分裂成小于10GB的128个分区需要分裂7轮，每一轮要执行一次Compaction（读取1TB数据，写出1TB数据），而且一个分区的Compaction只能由一台机器执行，所以第一轮最多只有2台机器参与，第二轮4台，第三轮8台。。。，并且实际中需要人为干预balance。整个过程做下来超过10小时，这还是假设没有新数据写入，系统负载正常。面对这个问题我们设计了“级联分裂”，可以不执行Compaction就进入下一次分裂，先快速的把分区拆分完成，然后一把执行Compaction。
前面讲的都是点，关于如何解决某个顽疾。导致系统失效的情况是多种多样的，特别一次故障中可能交叉着多个问题，排查起来异常困难。现代医学指出医院应当更多投入预防而不是治疗，加强体检，鼓励早就医。早一步也许就是个感冒，晚一步也许就变成了癌症。这也适用于分布式系统，因为系统的复杂性和自愈能力，一些小的问题不会立即造成不可用，比如内存泄漏、Compaction积压、队列积压等，但终将在某一刻引发雪崩。应对这种问题，我们提出了“健康诊断”系统，用来预警那些暂时还没有使系统失效，但明显超过正常阈值的指标。“健康诊断”系统帮助我们拦截了大量的异常case，也在不停的演进其诊断智能。
MTTR（mean time to repair）
百密终有一疏，系统总是会失效，特别的像宕机这种Case是低概率但一定会发生的事件。我们要做的是去容忍，降低影响面，加速恢复时间。HBase是一个可自愈的系统，单个节点宕机触发Failover，由存活的其它节点来接管分区服务，在分区对外服务之前，必须首先通过回放日志来保证数据读写一致性。整个过程主要包括Split Log、Assign Region、Replay Log三个步骤。hbase的计算节点是0冗余，所以一个节点宕机，其内存中的状态必须全部回放，这个内存一般可以认为在10GB~20GB左右。我们假设整个集群的数据回放能力是 R GB/s，单个节点宕机需要恢复 M GB的数据，那么宕机N个节点就需要 M * N / R 秒，这里表达的一个信息是：如果R不足够大，那么宕机越多，恢复时间越不可控，那么影响R的因素就至关重要，在Split Log、Assign Region、Replay Log三个过程中，通常Split Log、Assign Region的扩展性存在问题，核心在于其依赖单点。Split Log是把WAL文件按分区拆分成小的文件，这个过程中需要创建大量的新文件，这个工作只能由一台NameNode来完成，并且其效率也并不高。Assign Region是由HBase Master来管理，同样是一个单点。阿里HBase在Failover方面的核心优化是采用了全新的MTTR2架构，取消了Split Log这一步骤，在Assign Region上也做了优先Meta分区、Bulk Assign、超时优化等多项优化措施，相比社区的Failover效率提升200%以上。
从客户角度看故障，是2分钟的流量跌零可怕还是10分钟的流量下降5%可怕？我想可能是前者。由于客户端的线程池资源有限，HBase的单机宕机恢复过程可能造成业务侧的流量大跌，因为线程都阻塞在访问异常机器上了，2%的机器不可用造成业务流量下跌90%是很难接受的。我们在客户端开发了一种Fast Fail的机制，可以主动发现异常服务器，并快速拒绝发往这个服务器的请求，从而释放线程资源，不影响其它分区服务器的访问。项目名称叫做DeadServerDetective
容灾
容灾是重大事故下的求生机制，比如地震、海啸等自然灾害造成毁灭性打击，比如软件变更等造成完全不可控的恢复时间，比如断网造成服务瘫痪、恢复时间未知。从现实经验来看，自然灾害在一个人的一生中都难遇到，断网一般是一个年级别的事件，而软件变更引发的问题可能是月级别的。软件变更是对运维能力、内核能力、测试能力等全方位的考验，变更过程的操作可能出错，变更的新版本可能存在未知Bug。另一个方面为了不断满足业务的需求又需要加速内核迭代，产生更多的变更。
容灾的本质是基于隔离的冗余，要求在资源层面物理隔离、软件层面版本隔离、运维层面操作隔离等，冗余的服务之间保持最小的关联性，在灾难发生时至少有一个副本存活。阿里HBase在几年前开始推进同城主备、异地多活，目前99%的集群至少有一个备集群，主备集群是HBase可以支持在线业务的一个强保障。主备模式下的两个核心问题是数据复制和流量切换
数据复制
选择什么样的复制方式，是同步复制还是异步复制，是否要保序？主要取决于业务对系统的需求，有些要求强一致，有些要求session一致，有些可以接受最终一致。占在HBase的角度上，我们服务的大量业务在灾难场景下是可以接受最终一致性的（我们也研发了同步复制机制，但只有极少的场景），因此本文主要专注在异步复制的讨论上。很长一段时间我们采用社区的异步复制机制（HBase Replication），这是HBase内置的同步机制。
同步延迟的根因定位是第一个难题，因为同步链路涉及发送方、通道、接受方3个部分，排查起来有难度。我们增强了同步相关的监控和报警。
热点容易引发同步延迟是第二个难题。HBase Replication采用推的方式进行复制，读取WAL日志然后进行转发，发送线程和HBase写入引擎是在同一台RegionServer的同一个进程里。当某台RegionServer写入热点时，就需要更多的发送能力，但写入热点本身就挤占了更多的系统资源，写入和同步资源争抢。阿里HBase做了两个方面的优化，第一提高同步性能，减少单位MB同步的资源消耗；第二研发了远程消耗器，使其它空闲的机器可以协助热点机器同步日志。
资源需求、迭代方式的不匹配是第三个难题。数据复制本身是不需要磁盘IO的，只消耗带宽和CPU，而HBase对磁盘IO有重要依赖；数据复制的worker本质上是无状态的，重启不是问题，可以断点续传，而HBase是有状态的，必须先转移分区再重启，否则会触发Failover。一个轻量级的同步组件和重量级的存储引擎强耦合在一起，同步组件的每一次迭代升级必须同时重启HBase。一个重启就可以解决的同步问题，因为同时要重启hbase而影响线上读写。一个扩容CPU或者总带宽的问题被放大到要扩容hbase整体。
综上所述，阿里HBase最终将同步组件剥离了出来作为一个独立的服务来建设，解决了热点和耦合的问题，在云上这一服务叫做BDS Replication。随着异地多活的发展，集群之间的数据同步关系开始变得复杂，为此我们开发了一个关于拓扑关系和链路同步延迟的监控，并且在类环形的拓扑关系中优化了数据的重复发送问题。
BDS Replication
流量切换
在具备主备集群的前提下，灾难期间需要快速的把业务流量切换到备份集群。阿里HBase改造了HBase客户端，流量的切换发生在客户端内部，通过高可用的通道将切换命令发送给客户端，客户端会关闭旧的链接，打开与备集群的链接，然后重试请求。
阿里云同城主备
切换瞬间对Meta服务的冲击：hbase客户端首次访问一个分区前需要请求Meta服务来获取分区的地址，切换瞬间所有客户端并发的访问Meta服务，现实中并发可能在几十万甚至更多造成服务过载，请求超时后客户端又再次重试，造成服务器一直做无用功，切换一直无法成功。针对这个问题我们改造了Meta表的缓存机制，极大地提高了Meta表的吞吐能力，可以应对百万级别的请求。同时在运维上隔离了Meta分区与数据分区，防止相互影响。
从一键切换走向自动切换。一键切换还是要依赖报警系统和人工操作，现实中至少也要分钟级别才能响应，如果是晚上可能要10分钟以上。阿里HBase在演进自动切换过程中有两个思路，最早是通过增加一个第三方仲裁，实时的给每一个系统打健康分数，当系统健康分低于一个阈值，并且其备库是健康的情况下，自动执行切换命令。这个仲裁系统还是比价复杂的，首先其部署上要保持网络独立，其次其自身必须是高可靠的，最后健康分的正确性需要保证。仲裁系统的健康判断是从服务器视角出发的，但从客户端角度来讲，有些时候服务器虽然活着但是已经不正常工作了，可能持续的FGC，也可能出现了持续网络抖动。所以第二个思路是在客户端进行自动切换，客户端通过失败率或其它规则来判定可用性，超过一定阈值则执行切换。
极致体验
在风控和推荐场景下，请求的RT越低，业务在单位时间内可以应用的规则就越多，分析就越准确。要求存储引擎高并发、低延迟、低毛刺，要高速且平稳的运行。阿里HBase团队在内核上研发CCSMAP优化写入缓存，SharedBucketCache优化读取缓存，IndexEncoding优化块内搜索，加上无锁队列、协程、ThreadLocal Counter等等技术，再结合阿里JDK团队的ZGC垃圾回收算法，在线上做到了单集群P999延迟小于15ms。另一个角度上，风控和推荐等场景并不要求强一致，其中有一些数据是离线导入的只读数据，所以只要延迟不大，可以接受读取多个副本。如果主备两个副本之间请求毛刺是独立事件，那么理论上同时访问主备可以把毛刺率下降一个数量级。我们基于这一点，利用现有的主备架构，研发了DualService，支持客户端并行的访问主备集群。在一般情况下，客户端优先读取主库，如果主库一定时间没有响应则并发请求到备库，然后等待最先返回的请求。DualService的应用获得的非常大的成功，业务接近零抖动。
主备模式下还存在一些问题。切换的粒度是集群级别的，切换过程影响大，不能做分区级别切换是因为主备分区不一致；只能提供最终一致性模型，对于一些业务来讲不好写代码逻辑；加上其它因素（索引能力，访问模型）的推动，阿里HBase团队基于HBase演进了自研的Lindorm引擎，提供一种内置的双Zone部署模式，其数据复制采用推拉组合的模式，同步效率大大提升；双Zone之间的分区由GlobalMaster协调，绝大部分时间都是一致的，因此可以实现分区级别切换；Lindorm提供强一致、Session一致、最终一致等多级一致性协议，方便用户实现业务逻辑。目前大部分阿里内部业务已经切换到Lindorm引擎。
零抖动是我们追求的最高境界，但必须认识到导致毛刺的来源可以说无处不在，解决问题的前提是定位问题，对每一个毛刺给出解释既是用户的诉求也是能力的体现。阿里HBase开发了全链路Trace，从客户端、网络、服务器全链路监控请求，丰富详尽的Profiling将请求的路径、资源访问、耗时等轨迹进行展示，帮助研发人员快速定位问题。
总结
本文介绍了阿里HBase在高可用上的一些实践经验，结尾之处与大家分享一些看可用性建设上的思考，抛砖引玉希望欢迎大家讨论。
从设计原则上：
1.面向用户的可用性设计，在影响面、影响时间、一致性上进行权衡
MTTF和MTTR是一类衡量指标，但这些指标好不一定满足用户期望，这些指标是面向系统本身而不是用户的。
2.面向失败设计，你所依赖的组件总是会失败
千万不要假设你依赖的组件不会失败，比如你确信HDFS不会丢数据，然后写了一个状态机。但实际上如果多个DN同时宕机数据就是会丢失，此时可能你的状态机永远陷入混乱无法推进。再小概率的事件总是会发生，对中标的用户来讲这就是100%。
从实现过程上：
1. Un completo sistema de seguimiento El
seguimiento es la garantía básica y es el primer lugar donde se necesitan esfuerzos. Cobertura del 100% de las alarmas de avería Encontrar problemas antes que los usuarios es la primera tarea de monitorización. En segundo lugar, el monitoreo debe ser lo más detallado posible y la visualización de datos es amigable, lo que puede mejorar en gran medida la capacidad de ubicación del problema.
2. La redundancia basada en aislamiento
es una cura permanente para la disponibilidad Cuando se encuentran problemas desconocidos, es muy difícil que un solo clúster garantice el SLA. Por lo tanto, siempre que el dinero no sea malo, se debe proporcionar al menos un conjunto de maestro y respaldo.
3.
La anormalidad del sistema de control de recursos fino a menudo se debe a la falta de control del uso de recursos El control fino de CPU, memoria e IO es la clave para el funcionamiento estable y de alta velocidad del kernel. Necesita invertir muchos recursos de investigación y desarrollo para iterar.
4. Capacidad de autoprotección del sistema
En caso de sobrecarga de solicitudes, el sistema debe tener capacidades de autoprotección como Cuota para evitar avalanchas. El sistema debería poder identificar algunas solicitudes inusuales, restringirlas o rechazarlas.
5.Capacidad
de seguimiento El seguimiento en tiempo real de las trayectorias de las solicitudes es una herramienta poderosa para la resolución de problemas, y la creación de perfiles debe ser lo más detallada posible.