MongoDB - 《第一阶段》

ORM层—->JOOD
NoSQL和NewSQL（更新一点，旨在解决NoSQL不支持标准SQL语言和事务不全支持ACID属性的特点）
redis秒杀的实现方案！！！
以前mongodb不支持事务，不处理重要数据；现在支持了事务，可用性达到99.99%
mysql中myisam存储引擎中只有表锁，但是也可以并发插入，有一个concurrent_insert的参数可以设置，默认为auto，可以并发插入
mysql单机qps，读5000，写1000
mysql“日志先行”—->日志配置项：定期刷盘，时间间隔刷盘，默认是1，修改为2，性能会大幅上升（写的性能会大量提升）—->写的性能会大量提升，达到20000？六七千应该没问题（普通数据）
只是改一下数据，理论上达不到，因为做的是压测，实际上服务器上还要跑很多其他服务，实际情况下更复杂
达不到磁盘的读写速度，达到了少说也得有几万，远远没有达到磁盘的性能
MySQL单表300-500万，生产用户表1400万；一般在京东能到2000万，2000万之上会有问题（单表、纯物理机）—->5000万（老师没见过，同学见过）
2000万能扛住三两年的发展，超过2000万性能会严重下降
原生的MySQL，不是阿里改进的，MySQL5.6、MySQL5.7
性能扛不住—->分库分表—->MySQL数据量在几千万到几亿十几亿的规模，再往上就难了
MySQL单机100万毫无压力，500万的数据不用分表
过于复杂的查询不用MySQL去扛，他是扛不住的
mongodb都能用于实际的业务存储，不存在MySQL能干的事mongodb干不了，可以全干了；但是有些严格重要数据的场景要慎重
数据平台、数据中台
一般选择用mongodb都是因为数据量的问题，不是因为他好用
大批量的读写—->主要是写，一般写个几百上千就很不错了，一两千的写已经很巨大了
MySQL集群和分库分表与主从复制的关系
mongodb介于关系型数据库和redis之间
es：文本分词、查找、排序的数据库
现在OLTP早就覆盖OLAP数据库了
横向扩展（分片？）和纵向扩展（主从？）
扩展与数据库存储能力的关系
数据库大到一定程度有两种方案解决
1. 数据解转，转到历史，用到的可能性也不大了，按照数据的时间归档—->始终保持活跃的那张表不超过2000万—->基本上没问题——>京东的一些业务用得就是规整
2. 分库分表分片分区
MySQL的分库分表分片分区分别是什么？？？？
mongodb没几个api—->开发容易
360和百度存pb之上那个级别的数据—->海量
关系型数据库字段schema—->严格约束schema
mongodb的关键字查询也会比MySQL少多了
mongodb不支持表连接—->mongodb中用嵌入文档来解决表连接的问题，官方鼓励这么干
嵌套：一个类中有另一个的引用
阿里去IOE
Oracle的文档数据库就纯拿json去存的，而mongodb用bson（性能好）
灵活性高—->约束难，空间利用率不高
MySQL不太鼓励建外键索引
数字字典的表！！！！是什么
40-50张表中小型系统
mongodb尽量把连接查询做成一个模型
磁盘的查找中95%的时间是用来定位数据位于磁盘中的哪一盘块的，5%的时间用于数据的读取和存取
MySQL在生产环境新建表要经过流程审批
数据量大mysq加字段实在太痛苦了，随便一个简单字段就是6-7个小时
在线修改表结构，MySQL可能会锁表或者影响线上流程
, mysq加字段半夜两点整
用mongodb的主要原因是MySQL的性能跟mongodb没法比，MySQL的性能太差了
可以用mongodb全程做，东方航空
TP99、PV、QPS
fork命令的原理，是从一个已有线程复制出一个线程并且资源指针仍然指向同一个，只有在更新的时候才会指向自己独有的内存区域
零拷贝？——……
查询多的时候mongodb不是最好的方案，可以存到es中
写入数据多的时候可以用mongodb
查询慢可以考虑es查询—->mongodb介于es、redis、和mysql之间
mysql到三四万、五六万就很慢并且优化不了了，这时用es
mongodb查一些简单的业务场景还行，es适用于文本查询
solr和es底层都是loicence？
分片集、复制集、集群的区别
redis集群、代理、分片、哨兵的区别
正则表达式的写法
mongodb中的模糊查询是使用正则表达式来查询的
解决模糊搜索性能问题的方案：实现把数据存在缓存或者es中了，在那里面实现模糊搜索，精确出一个条件，再到表里去精准的匹配
正则：/手/ /^手/
商品详情可以存到redis数据库中，作为数据库而不是作为缓存
mongodb的解析引擎其实就是js引擎，语法格式和py和js基本一样
有解析经典sql为mongodb语法的解析引擎，但是不建议使用—->没必要
投影查询有，在聚合操作的时候也会对聚合结果进行投影
模型设计和分片
不是让代码多么完美，而是让代码尽快上线，之后再去优化他；
不可能一口吃个胖子，不可能一下子就能够完美
通过加版本号的方式，不同的版本使用不同的逻辑代码进行处理
mongodb结构方便，并且速度比MySQL快？
mongodb存上亿数据毫无压力，查询也是毫无压力
mysql一张表存几个g还可以，但是mongodb存几个g上pb都可以
淘宝京东一个订单可能就一两kB
表中还有辅助性字段（创建人、创建时间）+软删除+乐观锁等等七八个字段
阿里建议mysq|单个表的数量上千万后就要分表，mongodb需要分表吗
MySQL存个一千万两千万就差不多了
分库分表—->将一个数据表拆成多少个库然后上面搞个路由节点去路由他
几百万还没问题，不需要分表
mongodb数据达千万之后是不需要分表的
一条一条插入性能最低了，要批量插入！！！
对MySQL来说，批量插1000（万？）条也是没关系的？？？
4g4核的服务器插入mysql一条一条插入大概每秒六七百
多线程的情况下要记得使用concurrent包下的容器类copyOnWrite
NoSqlBooster for MongoDB
sku和spu
在聚合中，某一个字段（比如count）有（出现）就是1，没有就是0—->函数方法
好像跟Oracle一样，有闪回功能（MySQL？MongoDB？）
数据量大，统计维度复杂的时候（比如统计count），用MongoDB的聚合操作可能也会很慢，这时候建议使用数据中台，大数据部门，把关系型数据库或者mongoDB这种数据推给他们，让他们用一些流式的计算框架—->数据每天出实时的报表
不复杂的场景下毫无问题，中小型项目用mongodb做数据库用完全没有问题
特殊报表会慢，很多条件condition的count
TiDB
redis的主从原理、哨兵机制，集群；以及原生Java API和框架下的api（一种封装了的，一种没有封装的？？？）
微服务接口堆外提供服务的时候的asm包可能会因为版本出问题
mongodb超过5万count就很慢
三机房两中心，一种做备份的时候不会在同一个机房中，乃至不在同一个地方
副本集可以做数据分发，访问更近的节点，而不需要访问远的节点
mongodb事务必须使用副本集
zookeeper集群中节点的角色：leader、follower、observer
从节点同步用的是类似canal的方法？
RAFT一致性算法—->mongodb投票
选举—->奇数
必须严格超过一半，一半不行
zookeeper写数据或者干别的事情的时候也要投票（表示自己干完了）！！！CP
选举投票的时候可以给自己投票，所以只有两个节点的时候依然可以选举
要使用奇数台是针对没有挂掉的初始状态来说的，那样可以计算容错率，而不是在某些节点挂掉之后再从奇数台中选取的
zookeeper中的observer没有投票权—->在启动集群中直接设置observer即可，zookeeper集群的启动顺序，是怎样启动的，redis的集群是怎样启动的，是怎样配置的，zookeeper所有的节点用相同的配置吗？
节点优先级主要从两个方面考虑：
1. 地理位置，主节点呆在哪个位置，哪个地方的写请求比较多，哪个地方比较重要（CDN内容分发网络）
2. 服务器机房的物理配置的好坏，好的优先级更高
隐藏节点：读写数据的时候不对该节点发生，可以复制数据，可以有投票权，优先级必须是0
延迟节点：复制n秒之前的数据
只要是分布式吗，一定有延迟；延迟会不会影响使用？——>不一定，事务
延迟节点同步1小时之前的数据，假如执行了删除语句，那么延迟节点依然同步的是1小时之前的数据，即还没有同步删除语句，那么之前的数据就有可能可以恢复，损失就会降低
没有万无一失的东西，数据不是永远不会丢的，少执行一些敏感的命令
一般多机房多中心部署，硬件环境需要隔离
就算是放一个机房里，也不要放在同一个机柜中、同一个电源上
增加节点不会增加写性能，增加从节点主要用于增加读性能、提高可靠性，主要用于备份、容灾等，
新增节点的时候，主节点都有百分比的性能降低——>心跳机制
为什么最多只能七个节点投票通信？—->投票的节点越多通信越多oplog日志、网络请求越多；七是一个综合值；机器越多性能越低，越占用网络带宽；是一个中性值，不一定是最优的值；只要增加一台节点，集群的性能必然会下降；多了一个通信的人，多了一个访问数据、心跳的节点
oplogs是一个特殊的集合，记录所有对于数据库的增删改的行为日志
从节点通过异步方式获取oplogs，每一个从节点都有oplogs的副本
任何从节点都可以向其他任何节点发送心跳吗，可以从其他从节点同步oplogs
同步可能会失败，但是重试的时候要保证幂等性把用户，不会重复导入
手动同步：一台从节点挂了两个小时，在这两个小时之内，主节点新增的数据已经覆盖了oplogs的最大值，这时就无法正确同步，这时从节点会不断重试而无法成功；此时可以删掉从节点中的所有数据进行一次全量同步
正常的同步，包括oplogs日志都是非全量的同步
123中的情况，可能会从其他节点同步数据，因为其他节点的数据可能不是最新的，就有可能还没有覆盖掉之前的数据，因此可以同步？？？？？？？？？——>疑问
主节点挂了数据丢不丢？—->多级熔断降级的概念，到数据库那层的数据都得有点数据容错的处理—->先将数据放到消息中间件中去，之后再慢慢同步
如何提升写能力？——>分片集群
MySQL副本集—->主从；MySQL分片集—->分表（把表分到不同数据库中，可以同时多写）
数据丢失问题：拿MQ挡一下积压，主节点不会那么容易挂，真挂了选举不会太慢，几秒内的数据还是能够抗住的；要事先想好这些问题—->实际中遇到这样的瓶颈一定要处理
数据发出去了，db或者消息队列挂了怎么办，经常被问
分表的问题：怎么扩容，事先怎么分表（分区依据）
分页和MySQL一样limit skip main—->根据索引列去分，不要skip一下又limit一下（MySQL数据量大的时候也慢）；id是连续的时候会很快
经不起完美的推敲——>count时已经处理很多情况了，（关系型数据库：分页很快，count很慢，索引没生效！）—->少去连表，多去冗余一点
关系型数据库设计的时候互联网公司是不提倡主外键的（学的时候会有主外键）
mongodb的索引结构都是b树的，所以删除的时候可以用一个假删除，连续的时候查询较快，而真删除的时候会重建索引这样会降低效率
分表后只提升了写性能，还要进行聚合就会降低读的效率；
数据量大的时候不适合分页操作，淘宝等网站很少有分页以及全量查询数据的地方
mongodb单表存了一亿还不是很大，MySQL存了上千万就该考虑考虑了
一张表3g的索引
条件查询看条件能不能落在索引列或者id上，和MySQL差不多
查询条件太多导致索引失效，索引未必走
电商网站的商品分类，销量价格等排序可以考虑用es去做
mongodb聚合框架不擅长做分面，从什么价格到什么价格之类的这种或者类型的分类
redis做数据库的时候可以存放商品的详情页
把整个文档放在es中去检索，或者把整个索引列放在es中（MySQL和mongodb的索引列），从es中读取来之后再去读原来的表
mongodb可以存放图片和视频
京东规范中禁止使用text或者blob等二进制类型，别用他干他不擅长的事情
禁止存储大文件或者大照片，存在文件系统中多好，数据库中存储uri即可—->白天事情很少、很忙？不会要跟别人说，没必要装一个什么都会的人
用户头像可以存在数据库中（小图片），比如电商网站中的商品详情页的商品图片（可放大的图片）—->图片压缩算法！！！
前端debug的network中的过滤查询是什么？？？？❓filter过滤
网站的图片可能放到一些**云存储**上了，img30.xxxx.com……
存对象存储里
计算能力上移（计算向存储移动？？？？）：数据库能算的东西如果应用程序能算放到应用程序中，应用程序能算的如果客户端能算，放到客户端中去，将压力往上移（压力上行！）
图片放到云存储上时可以统一的管理，并且突破了本机的硬盘、大小的限制
CDN分发也不是存到一个节点上，而是对用户的访问进行就近的访问CDN服务器也可以自己搭
CDN技术！！！—->就近访问，不好确认哪个近，根据网络跳点的概念就近的去访问；分发出去之后就会有缓存信息了，这些缓存不用自己去处理，他自己处理好了；这种存储的**性能还是很稳定的，并且数据还不容易丢失**！！！
七牛云、阿里云本身就是做这种CDN服务的
自己搭可以用DFS之类的，但是自己搭很耗费资源—->阿里云3年99元
专业的CDN服务提供商提供的服务带宽是很强大的，自己的服务器扛不住那么大的带宽；不光如此，自己的机器还有带宽和IO读写性能、吞吐量的限制
视频播放不放到专门的视频播放服务器上，10个用户同时访问，即使带宽够用也会很卡，因为用户实时的从硬盘上读取数据，但是根本没有这样的能力
云存储会好一点
自己统计每张图片的访问量很痛苦，可以给云存储或者CDN来干
mongodb的副本集最多可以有50个成员，但是只有7个投票成员；类似于zookeeper中的leader、follower、observer的角色划分
副本集必须有一个主节点，只有主节点能写数据，所有节点都能读取数据,但默认数据只从主节点读取，从节点不读取，可配置Read Preference更改
不推荐使用投票节点(Arbiter)—->往上的资料：一主一从+一投票节点，不推荐使用投票节点（仲裁），都是用副本集了，不差这一台机器的钱；投票节点不会存储数据（只参加投票选举），主节点挂了之后就只剩一个从节点了
具有投票权的节点之间两两维持着一个心跳
选举算法：RAFT一致性算法；成功的必要条件是大多数投票节点存活
选举的大多数不是目前还活着的大多数，而是原来最初所有节点全部活着的大多数！！！—->这个大多数是不会变的，当少于大多数的时候就不能进行选举了（与zookeeper类似）
从节点同步类似canal？？？
建议配置主机名**hostname -f**，因为一个机器可能有多个网卡、多个ip？？？？，这就造成了用ip不太行；用云主机可能会好一些？？？
云主机是什么？云是什么？
linux参数一根小短横是参数的简写，两根小短横是参数的全称
一个ip上可以有好多个域名
域名和主机名的区别与联系？？？？❓ ``` 主机名和域名的联系与区别如下：

1、Internet域名是Internet网络上的一个服务器或一个网络系统的名字,在全世界,没有重复的域名。域名的范围要比主机名大。一个域名下可以有多个主机名,域名下还可以有子域名。例如,域名cnwg.cn下,有主机server1和server2,其主机全名就是server1.cnwg.cn和server2.cnwg.cn 2、主机名的含义是机器本身的名字，域名是方面记录IP地址才做的一种IP映射；二者有共性：都能对应到一个唯一的IP上，从应用场景上可以这么简单理解二者的区别：主机名用于局域网中；域名用于公网中。域名结构：域名由两个或两个以上的词构成，中间由点号分隔开。最右边的那个词称为顶级域名。举例：（1）、COM—用于商业机构。它是最常见的顶级域名。任何人都可以注册.COM 形式的域名。（2）、.NET—最初是用于网络组织，例如因特网服务商和维修商。任何人都可以注册以.NET结尾的域名 ```

PB之上是EB！
一般生产中的集群用三台机器就够了，除非有别的特殊需求
其他副本集的一些操作
用IP可能会出问题
mongodb集群中建议使用主机名hostname
主节点挂了或者修改了配置会重新选举
mongodb shell命令是支持js语法的，可以赋值变量取值等
操作集群、配置集群的命令在主节点上操作
选举的时候有一部分服务可能会被停掉，不向外提供服务；可以通过架构上的知识解决
不差钱可以设置延迟节点防止误删
设置优先级只要是为了不让主节点从北京到四川去，或者到带宽、资源相对少一点的机房机柜中去
节点切换之后，程序如何自动识别自动连接到新的节点上去（将生产故障时间降到最低）？
1. 这是连接驱动干的事情—->redis和es也是，连接驱动内部会做一些心跳的转发，你就算连一个节点他也会连接整个集群
2. zookeeper在代码中连接的时候是将所有的节点的ip:port作为参数传到构造方法中去
3. 而mongodb连接的是主节点或者从节点中的某一
同步默认是增量复制不是全量复制，即使用oplogs；而全量的初始化赋值是全量的
初始同步主要用在增加节点的情况下（加一个新的节点全量同步）
市场上有很多产品是通过日志log进行数据的解转、转移、备份（mysql、mongodb等）
mongodb支持50个副本集，但是3个用的是最多的
生产环境单机10%，分片20%，剩余的都是副本集，三台机器就够了（能撑起很大的数据量）；假如数据量再大就想办法提升硬件性能（读写性能），或者考虑使用分片集群
数据库建模：概念（对象—->需求分析）-逻辑（属性—->架构师及开发者）-物理（关系—->开发者、DBA）
概念：描述业务系统要管理的对象
逻辑：基于概念模型，详细列出所有实体、实体的属性及关系
物理：根据逻辑模型，结合数据库的物理结构，设计具体的表结构，字段列表及主外键
BRD评审、PRD评审？
DBA（BI）去设计表，90%是开发自己定
和用户沟通生成PR文档，直接进行数据库设计
之前数据库设计遵循三范式，这样不会冗余，现在实际中很少遵守三范式—->主观不遵守了，因为会对性能有些影响，要把计算上移，从数据库层移到应用层—->反三范式
数据库层面的完整体系层面知识
误区：有时候不需要建立数据模型，不需要什么模型设计可以用一种collection从头走到尾，没必要刻意去用嵌套什么的；mongodb应用通常用一个大文档解决所有数据模型—->有时候需要嵌套
mongodb支持关联和事务
🌟文档模型设计原则：
1. 逻辑上，文档模型设计属于物理模型设计阶段
2. 通常通过内嵌数据（数组）+引用字段（不是物理上的强关联，没有严格的主外键约束，而是一个标记）来表示关系
3. 不遵从第三范式，允许冗余
4. 性能+易用

关系型数据库禁止使用存储过程、视图、触发器、Event
1. 解读:高并发大数据的互联网业务,架构设计思路是“解放数据库CPU,将计算转移到服务层”，并发量大的情况下，这些功能很可能将数据库拖死，业务逻辑放到服务层具备更好的扩展性,能够轻易实现”增机器就加性能”。数据库擅长存储与索引，CPU计算还是上移吧
2. 不要让数据库干一些计算的事情！！！
3. 代理、负载均衡向数据库移动
关系型数据库命名规范：只允许使用内网域名，而不是ip连接数据库！
从库在名称后加-s标识，备库在名称后加-ss标识
表名t_ xxx,非唯一索弓|名idx xxx,唯一索引名uniq. xxx
唯一索引是有实际价值的
实际工作中数据库运维上的最大体验就是：很多程序出问题都是出现在幂等性上了，很多很大—->架构的升级改造也全是因为幂等性问题
关系型数据库删除无主键的表的时候，在row模式（row模式和statement模式：一个是行数据，一个是语句，优先使用statement模式）的主从架构会导致备库夯住
关系型数据库禁止使用外键，如果有外键完整性约束，需要应用程序控制
1. 解读:外键会导致表与表之间耦合，update与delete操作都会涉及相关联的表，十分影响sq|的性能,甚至会造成死锁。高并发情况下容易造成数据库性能下降，大数据高并发业务场景数据库使用以性能优先（以性能优先）
没有银弹，根据具体业务去写具体的工具类
关系型数据库的字段必须定义为NOT NULL并且提供默认值
1. null可能会造成索引失效，也有可能不会使索引失效（不要纠结这个）
2. null的列使索引索引统计/值比较都更加复杂,对MySQL来说更难优化
3. null 这种类型MySQL内部需要进行特殊处理，增加数据库处理记录的复杂性;同等条件下，表中有较多空字段的时候，数据库的处理性能会降低很多
4. null值需要更多的存储空，无论是表还是索引中每行中的null的列都需要额外的空间来标识
5. 对null的处理时候，只能采用is null或is not null,而不能采用=、in. <、<>. !=、not in这些操作符号。如: where name!=’ shenjian’ ，如果存在name为null值的记录,查询结果就不会包含name为null值的记录。
禁止使用小数存储货币（容易导致钱对不上）
不适用枚举，多使用TINYINT代替—->状态机的查询
1. 枚举内部存储实际上还是整数，只不过对应关系存在表结构中
2. 增加新的enum值要做ddl操作
status禁止这么用，你要写成有逻辑意义得字段,比如用户状态, userStatus, is_ delete ,不要存成int类型，而是用tinyint
离线型需求、实时性需求—->是直接查出来在service层聚合还是直接聚合到service层（aggregate有时候不是很快，复杂的聚合会是分钟级的），聚合语句可能比自己写更方便！
单表索引建议控制在5个以内
单索引**字段数**不允许超过5个（不允许有5个以上的单索引还是一个组合索引中的字段数不能超过5个？？？？？后者）
不在更新频繁、区分度不高的属性上建立索引
禁止使用SELECT *,只获取必要的字段,需要显示说明列属性
1. 解读:
  1. 读取不需要的列会增加CPU、I0、NET消耗
  2. 不能有效的利用覆盖索引
  3. 使用SELECT *容易在增加或者删除字段后出现程序BUG
禁止使用OR条件，必须改为IN查询—->OR会导致索引失效
同表的增删字段、索引合并一条DDL语句执行（可能要上线审批），提高执行效率，减少IO，减少锁占用的时长，减少与数据库的交互。
总结:大数据量高并发的互联网业务,极大影响数据库性能的都不让用
类似于DDD领域驱动模型：拿到一个需求，拿到一个项目，拿到一件事情的时候，先别着急
1. 先拆，把所看所思所想的东西以名词的方式列出来
2. 明确模型对象之间的关系（1-1还是1-N还是N-N）
  1. 简单的看这么做合不合理，尝试一种技术方案，没有过多考虑，看可不可以
3. 根据关系建模—->具体关系怎么具体建表
  1. 1-1内嵌为主，以字段表示
    1. 例外情况：内嵌后，文档大小不应该超过16M限制—->BSON文件的最大大小为16MB—->避免占用过多RAM内存与传输中占用过多带宽
  2. 1-N内嵌为主，以数组表示
    1. 文档大小不能超过16M，数组长度不能太大（数万，其实1000以上查询性能就会降低），具体长度按需求决定（文档大小上1KB的都很少，一般是700B-800B，这里的16M不包括索引，只是文档的大小，索引是单独存储的）
    2. 几百还好，上千就不行了（MySQL也一样）
    3. 应用程序传的字符串先要经过应用服务器的处理与传输，这时会有性能损耗——>mybatis有性能损耗（尤其是使用了各种插件mybatis-plus……，由spring代理之后性能会依次递减），对象传来传去；最快的还是原生的jdbc
  3. N-N关系型数据库主要使用新建一个关联表来实现，而文档类型数据库使用内嵌数据通过冗余实现N-N
    1. 两两中都包含另一个
  4. 有可能不会冗余所有的字段，只冗余需要用到的字段，相当于关联表
lookup相当于left join，mongodb不能用于大表或者分片表—->公司人再多也不会超过一个分片的大小，因此可以嵌套使用
主要考虑读写性能

要么引用，要么冗余，只需要考虑读写性能的比例即可
什么时候使用引用？
1. MySQL关联的时候
2. 内嵌文档太大，数MB
3. 超过16MB一定不能用引用？？？
4. 内嵌文档或数组持续增长，确定不了限制不用冗余？
能用的模型（2种：从技术上选择）：
1. 单表上能够查询到的数据
2. 解决关联
冗余用在数据基本不变的情况下，冗余的模块没有必要单独做一张表去做业务逻辑的处理；能不关联尽量不关联，关联效率低；关联表很难优化甚至不好优化—->优化了关联就不能优化排序
能用冗余就用冗余，不能用就用引用（用不了用引用）
数据的设计模式！！！！疑问？没看懂！！
游戏积分排行—->redis
asas
DeepL翻译软件！！！！
通常应用程序都会做一二级缓存
mybatis的缓存也是为了降低应用层带来的损耗
面试：对某一个点有自己独到的理解，而不是知识点的多与少！！！—->分析问题的能力
大厂：工作经历不能太多（五二原则：五年内两个工作，别经常换，硬性指标只能造假），本科
priority属性的优先级大于oplogs版本的优先级
SLA？？？
节点宕机的时候应用程序可能会挂，一般会有多级缓存
zookeeper先看transaction_id，再看id
三级都挂了就挂吧，认命吧，就不可用了
连接池缓存？
阿里：十年进两家