为了更好地开展课题研究，我们围绕着金融行业分布式数据库HTAP混合应用负载业务系统需求，针对性的发出了需求调研表，从民生银行、建设银行、邮储银行、兴业银行、中信银行、光大银行、吉林农信、上海银行的积极反馈中，可以看出，联机事务交易处理与联机分析处理的业务需求较为明显，业务场景涉及：账户类实时交易处理与账户级统计数据查询，交易数据处理、账户数据跑批，同时需要快速出具下游汇总数据及报表，日间联机交易与实时分析统计，大量的批处理作业采用存储过程和ETL工具完成。遇到的瓶颈是资源相互争用，无法同时兼顾实时联机访问和批量数据计算，体现在实时统计分析对联机业务处理产生的性能影响，业务的优先级上，首先保证交易正常处理，同时要求统计分析数据的准确性。对联机交易和联机分析的处理时间有较高的要求，分别是毫秒级和秒级，希望对HTAP混合应用负载实现资源隔离，支持快速灵活的资源调整和分配，满足不同计算场景的需求，数据库存储空间的动态、在线扩容及收缩，资源管理计划能定义不同的优先级、阀值、调整策略，灵活管理IO、CPU、并行查询与并行执行计划等。
分布式数据库HTAP技术特性
新一代NewSQL分布式数据库技术，基于“计算-存储”分离架构，有效地应对了HTAP混合应用负载所面临的主要技术挑战，在同一数据存储上，充分利用多个一致性数据副本及数据访问隔离技术，通过多SQL引擎与Spark生态相结合，在提高联机交易和联机分析工作负载的效率的同时，防止分析查询对联机业务操作的干扰。
分布式数据库“计算-存储”分离架构
分布式数据库弥补了NoSQL在标准SQL支持及事务ACID处理方面的不足，适用于高并发、低延迟的OLTP应用场景，分布式NewSQL数据库采用“计算-存储”分离的架构，将协议解析、计算等模块与底层存储解耦，存储层通过垂直、水平的数据切分实现弹性扩张，计算层采用无状态设计，独立部署，通过动态增加数据库实例线性提升计算能力，有效应对瞬时爆发的高并发海量交易，满足微服务架构对“去中心化”数据管理，轻量部署、弹性（快速修复）的要求。
分布式数据库是物理上分散而逻辑上集中的数据库系统，利用分布式事务处理、数据自动分片、数据多副本存储等技术，将分散在计算机网络的多个逻辑相关的数据库节点连接起来，共同对外提供服务。
分布式数据库多副本数据一致性与隔离访问
分布式数据库采用数据多副本机制确保分布式环境下数据的高可用，多个数据的副本分别驻留在不同物理服务器的内置存储设备上，联机分析结果的准确性是由分布式数据库多数据副本的数据一致性保证的。
在分布式HTAP数据库中，用户可以针对多个数据副本，在节点和会话等多个级别指定HTAP分离与定向访问策略，使不同类型的业务应用（联机交易、联机分析）采用各自的开发接口（例如 MySQL、SparkSQL），能够访问相同的数据，资源相互隔离、运行互不干扰。
在多数据副本机制中，主副本提供读、写服务，从副本提供只读服务，通过一致性算法实现数据同步。目前，业界的分布式数据库产品通常采用分布式一致性协议有：Paxos和Raft。
Paxos算法
Paxos算法一种基于消息传递的分布式一致性算法，获得2013年图灵奖。
Paxos算法解决的问题是分布式一致性问题，利用多数派 (Majority) 机制保证了2F+1的容错能力，即2F+1个节点的系统最多允许F个节点同时出现故障。
在多副本状态机中，每个副本同时具有Proposer、Acceptor、Learner三种角色，Proposer负责提出提案，Acceptor负责对提案作出裁决（accept与否），learner负责学习提案结果。
Paxos算法伪代码
Raft算法
Raft算法的设计思路就是将复杂的问题简单化，把一组服务器的数据一致性问题分解为3个小问题。这3小问题包括：
· 领导选举：当现存的领导人宕机的时候,一个新的领导人需要被选举出来
· 日志复制：领导人必须从客户端接收日志然后复制到集群中的其他节点，并且强制要求其他节点的日志保持和自己相同。
· 安全性：在 Raft 中安全性的关键是状态机安全：如果有任何的服务器节点已经应用了一个确定的日志条目到它的状态机中，那么其他服务器节点不能在同一个日志索引位置应用一个不同的指令。
Raft算法还简化了复制状态机的数量，每台服务器一定会处于三种状态：领导人（Leader），候选人（Candidate），追随者（Follower）。状态的转换如图所示：
Raft算法状态转换
