18 | 正确性案例（中）：常见分布式数据方案的设计原理是什么？

老师课程前半部分比较多关于金融系统的业务逻辑，后面倒是比较偏技术实现。有没有考虑再出一系列课程专门介绍更多金融系统的业务逻辑、牵涉到的机构。本身不是从事金融相关技术，对真实世界金融系统的运作还不是很了解

对课后问题是否可以换个角度来思考。数据库无非就是支持数据查询、修改等等操作。而我们平时的业务系统对外暴露的也是查询、修改等等操作。从外部来看，两者行为上是类似的。 那么课后的问题就可以更换为，在分布式的情况下如何保证业务的正常运行。似乎就会熟悉些。 比如缓存我们使用Redis、单机事务使用mysql、索引分区配置等等。

作答如下，有的就是一些堆砌，逻辑还不是很顺。 首先，数据库是有状态的，最终目的是为了存储数据，基于老师在这节课中的内容，应该有以下的几个考虑： • 稳定性（高可靠、高可用） • 正确性（各种一致性与隔离级别） • 速度。这里把速度对应到性能，性能又做出如下的分解： ○ 读性能 ○ 写性能 ○ 存储空间 1、表存储 表存储主要目的是存储数据。这层不考虑事务（即正确性）、读写性能（即速度）。主要考虑数据量及存储空间。为什么呢？参考对MYSQL的理解，为了保证写入性能以及稳定性（crash safe），用的是WAL（write ahead log）；为了保证读取性能，用的是索引。 同时，在具体操作数据时，是以页为单位进行的，且不是直接在硬盘上进行，而是将数据映射到内存页中，在内存页中进行修改后，然后刷盘。对内存页修改的依据一般就是顺序写的日志如redolog，因为日志里记录的是各种操作，我的理解就是复制状态机用到的命令。 此外，写的正确性还涉及到索引，如唯一索引就必须对数据做校验以满足唯一性。 应对大数据量，就是分片了。数据分片后也会提高性能。数据分片底层可以用分库分表，也可以采用各种线程的KV存数，比如这里的ROCKSDB。 分片之间需要同步数据，同步数据也是基于日志的，即老师讲过的 2、主索引和二级索引 索引主要是为了提高读取性能。读取数据的目的又有两种：在线交易(OLTP)和数据分析(OLAP)，应该根据数据库的使用场景不同，设计不同的索引结构。 数据的存储分片后，对应的索引应该如何存储呢？能想到的是索引和对应的存储采用一样的分片策略，每个存储节点上都有自己的索引，然后在主节点（有主节点，就默认了只有它对外提供服务）上建立一个数据和节点的对应关系（这个就是主索引么？）。对于跨分片的查询，将查询分发到相应节点上。 这里就成了用多台MYSQL，然后前面加一个数据库中间件，比如SHARDING SPHERE。 3、缓存 先做一个假设：缓存就是用空间换时间，且只缓存热点数据。那么需要缓存的数据就是少的，所以要不直接使用REDIS吧。缓存和DB的一致性就使用常用的哪些，比如cache aside之类的。 4、表的复制和容灾 将日志通过消息队列发送到其余分片，消息队列后对接底层存储本身支持的复制机制。 5、单机事务 如果底层支持，如为MYSQL，则用底层的事务。如果底层不支持，在服务层利用REDIS、zookeeper来实现。 6、分布式锁 用REDIS实现活用ZOOKEEPER等实现，前者应该性能更好吧。 7、分布式事务 可以用： • 2PC，性能太差 • TCC，对业务侵入较多 • 或者利用实现了线性一致性的系统。 • 或者在业务层实现，即用REDIS实现的分布式锁。 分布式事务就是要做到分布式的一致性。可以用锁来实现，锁能实现是因为可以用它实现冲突可串行化。 但是用锁来解决冲突，性能太低。分布式事务是要解决隔离性和一致性，所以还是要根据操作类型采用对应的手段： • 解决读写冲突：采用MVCC，通过版本来解决重读——使用没有冲突的数据版本，自然就没有哦冲突了。 • 解决写写冲突： ○ 如果压力不是很大，可以用乐观协议； ○ 如果压力很大，还是用悲观锁