在电梯远程监控中的应用

HA 与异地多活

主从模式并不是最优的方式，就算是半同步复制，在极端情况下(半同步转异步)也存在丢数问题。

目前业界公认更好的方案是基于 Paxos 分布式一致性协议或者其他类 Paxos 如 Raft 方式，Google Spanner、TiDB、cockcoachDB、OB 都采用了这种方式。

基于 Paxos 协议的多副本存储，遵循过半写原则，支持自动选主，解决了数据的高可靠，缩短了 Failover 时间，提高了可用性，特别是减少了运维的工作量，这种方案技术上已经很成熟，也是 NewSQL 数据库底层的标配。

当然这种方式其实也可以用在传统关系数据库，阿里、微信团队等也有将 MySQL 存储改造支持 Paxos 多副本的，MySQL 也推出了官方版 MySQL Group Cluster，预计不远的未来主从模式可能就成为历史了。

分布式一致性算法本身并不难，但具体在工程实践时，需要考虑很多异常并做很多优化，实现一个生产级可靠成熟的一致性协议并不容易。

例如实际使用时必须转化实现为 multi-paxos 或 multi-raft，需要通过 batch、异步等方式减少网络、磁盘 IO 等开销。

需要注意的是很多 NewSQL 数据库厂商宣传基于 Paxos 或 Raft 协议可以实现【异地多活】，这个实际上是有前提的，那就是异地之间网络延迟不能太高。

以银行“两地三中心”为例，异地之间多相隔数千里，延时达到数十毫秒，如果要多活，那便需异地副本也参与数据库日志过半确认，这样高的延时几乎没有 OLTP 系统可以接受的。

数据库层面做异地多活是个美好的愿景，但距离导致的延时目前并没有好的方案。

之前跟蚂蚁团队交流，蚂蚁异地多活的方案是在应用层通过 MQ 同步双写交易信息，异地 DC 将交易信息保存在分布式缓存中。

一旦发生异地切换，数据库同步中间件会告之数据延迟时间，应用从缓存中读取交易信息，将这段时间内涉及到的业务对象例如用户、账户进行黑名单管理，等数据同步追上之后再将这些业务对象从黑名单中剔除。

由于双写的不是所有数据库操作日志而只是交易信息，数据延迟只影响一段时间内数据，这是目前我觉得比较靠谱的异地度多活方案。

另外有些系统进行了单元化改造，这在 Paxos 选主时也要结合考虑进去，这也是目前很多 NewSQL 数据库欠缺的功能。

Scale 横向扩展与分片机制

Paxos 算法解决了高可用、高可靠问题，并没有解决 Scale 横向扩展的问题，所以分片是必须支持的。

NewSQL 数据库都是天生内置分片机制的，而且会根据每个分片的数据负载(磁盘使用率、写入速度等)自动识别热点，然后进行分片的分裂、数据迁移、合并，这些过程应用是无感知的，这省去了 DBA 的很多运维工作量。

以 TiDB 为例，它将数据切成 Region，如果 Region 到 64M 时，数据自动进行迁移。

分库分表模式下需要应用设计之初就要明确各表的拆分键、拆分方式(Range、取模、一致性哈希或者自定义路由表)、路由规则、拆分库表数量、扩容方式等。

相比 NewSQL 数据库，这种模式给应用带来了很大侵入和复杂度，这对大多数系统来说也是一大挑战。

分库分表模式也能做到在线扩容，基本思路是通过异步复制先追加数据，然后设置只读完成路由切换，最后放开写操作，当然这些需要中间件与数据库端配合一起才能完成。

这里有个问题是 NewSQL 数据库统一的内置分片策略(例如 TiDB 基于 Range)可能并不是最高效的，因为与领域模型中的划分要素并不一致，这导致的后果是很多交易会产生分布式事务。

举个例子，银行核心业务系统是以客户为维度，也就是说客户表、该客户的账户表、流水表在绝大部分场景下是一起写的。

但如果按照各表主键 Range 进行分片，这个交易并不能在一个分片上完成，这在高频 OLTP 系统中会带来性能问题。

分布式 SQL 支持

常见的单分片 SQL，这两者都能很好支持。NewSQL 数据库由于定位与目标是一个通用的数据库，所以支持的 SQL 会更完整，包括跨分片的 Join、聚合等复杂 SQL。

中间件模式多面向应用需求设计，不过大部分也支持带拆分键 SQL、库表遍历、单库 Join、聚合、排序、分页等。但对跨库的join以及聚合支持就不够了。

NewSQL 数据库一般并不支持存储过程、视图、外键等功能，而中间件模式底层就是传统关系数据库，这些功能如果只是涉及单库是比较容易支持的。

NewSQL 数据库往往选择兼容 MySQL 或者 PostgreSQL 协议，所以 SQL 支持仅局限于这两种，中间件例如驱动模式往往只需做简单的 SQL 解析、计算路由、SQL 重写，所以可以支持更多种类的数据库 SQL。

SQL 支持的差异主要在于分布式 SQL 执行计划生成器，由于 NewSQL 数据库具有底层数据的分布、统计信息，因此可以做 CBO，生成的执行计划效率更高。

而中间件模式下没有这些信息，往往只能基于规则 RBO(Rule-Based-Opimization)。

（编辑：莆田站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!