JavaEdge全是干货的技术号

并发控制机制的划分方法很多，没有统一标准，使用提出的划分标准，分为悲观协议与乐观协议两种。这里的乐观协议是上一讲提到的狭义乐观协议，悲观协议又分为锁和非锁两大类，我们简单介绍了2PL这一个分支。我们回顾了Percolator模型，按照S2PL的定义，Percoloatro本质就是S2PL，因此TiDB的乐观锁也属于S2PL。S2PL是数据库并发控制的主流技术，但是锁管理复杂，在实现串行化隔离级别时开销太大。而后，我们讨论了非锁协议中的串行化图检测（SGT）。

OLTP通过ETL与OLAP衔接，所以OLAP数据时效性通常T+1，不能及时反映业务变化。这问题两种解决思路：重建OLAP体系，通过流计算方式替代批量数据处理，缩短OLAP的数据延迟，典型代表是Kappa架构；Gartner提出的HTAPHTAP的设计要点在计算引擎和存储引擎，其中存储引擎是基础。对于存储引擎也两种不同的方案，一种是以PAX为代表，用一份物理存储融合行式和列式的特点，Spanner采用了这种方式。

存储过程移植差。高度依赖数据库环境，而数据库环境不像操作系统或虚拟机那样遵循统一的标准。因为同样的原因，存储过程调试也很复杂，也没有跟上敏捷开发的步伐，与今天工程化的要求不匹配。正是因为这两个工程化方面原因，不用或少用存储过程分布式数据库角度，多数NewSQL还不支持存储过程，OceanBase作为唯一的例外，已经支持Oracle存储过程，但仍然没有达到生产级。F1的论文提出了独立UDF Server的思路，是分布式架构下存储过程的一种实现方案，但能不能适合普通的企业网络环境，尚待观察。

分片元数据的存储是分布式数据库的关键设计，要满足性能和高可靠两方面的要求。静态分片相对简单，可以直接通过多副本分散部署的方式实现。动态分片，满足高可靠的同时还要考虑元数据的多副本一致性，必须选择合适的复制协议。如果搭建独立的、小规模元数据集群，则可以使用Paxos或Raft等协议，传播特点是广播。如果元数据存在工作节点上，数量较多则可以考虑Gossip协议，传播特点是谣言传播。虽然Gossip是最终一致性，但通过一些寻址过程中的巧妙设计，也可以满足分布式数据的强一致性要求。

仅用“OLTP场景”作为定语显然不够精准，我们来进一步看看OLTP场景具体的技术特点。写多读少，指请求数量。而且读操作的复杂度较低，一般不涉及大数据集的汇总计算低延时，用户对于延时的容忍度较低，通常在500毫秒以内，稍微放大一些也就是秒级，超过5秒的延时通常是无法接受的；高并发，并发量随着业务量而增长，没有理论上限。分布式 DB是服务于写多读少、低延时、高并发的OLTP场景的 DB。写多读少、低延时、海量并发、海量存储、高可靠性、关系型 DB。