一些乱七八糟的东西
MySQL：关系型数据库，主要面向OLTP，支持事务，支持二级索引，支持sql，支持主从、Group Replication架构模型（本文全部以Innodb为例，不涉及别的存储引擎）。
HBase：基于HDFS，支持海量数据读写（尤其是写），支持上亿行、上百万列的，面向列的分布式NoSql数据库。天然分布式，主从架构，不支持事务，不支持二级索引，不支持sql。
ElasticSearch：ES是一款分布式的全文检索框架，底层基于Lucene实现，虽然ES也提供存储，检索功能，但我一直不认为ES是一款数据库，但是随着ES功能越来越强大，与数据库的界限也越来越模糊。天然分布式，p2p架构，不支持事务，采用倒排索引提供全文检索。
空回滚：pre阶段超时，此时rollback
事务悬挂：pre延时，rollback执行后，pre到达，然后执行了pre
如图：
1.A处理事务时，先向消息中间件发送一条消息，中间件进行消息持久化并返回应答；
2.A收到应答后开始处理并提交事务，提交成功后向消息中间件发送Commit请求（此时有可能发丢，如果发丢，由消息中间件的事务回查机制完成）
3.消息中间件收到Commit请求后便向B投递该消息；
4.B收到后开始处理事务，处理成功后向消息中间件返回应答
5.如果向B中途发丢来消息，则消息中间件重新投递该消息
注：消息中间件有一个回查任务，定期扫描非最终态的消息，向上游回查
TCC模型：是2PC的一种扩展，是基于编码实现的，用业务逻辑来实现2PC的功能。
TCC 自编码的特性决定 TCC 资源管理器可以跨数据库、跨应用实现资源管理，将对不同的数据库访问、不同的业务操作通过编码方式转换一个原子操作，解决了复杂业务场景下的事务问题。同时 TCC 的每一个操作对于数据库来讲都是一个本地数据库事务，操作结束则本地数据库事务结束，数据库的资源也就被释放；这就规避了数据库层面的 2PC 对资源占用导致的性能低下问题。
1.原理：
利用发号器，每次生成时，生成一个唯一短的ID。eg：每次生成短URL，发号器从0开始递增，那么生成的短URL可能是：t.cn/0 t.cn/1 …….
2.问题：
1）如何访问短URL时，跳转到原链接：将短URL与长URL做key-value映射，存Redis，每次访问查询一次。
2）如何保证同一长URL生成短URL时前后生成的一致：维护一个LRU本地缓存列表，映射长URL和短URL，当同一URL短时间多次生成时，返回前面生成的，当长时间没有生成时，根据LRU原则，从缓存中删除。（注：如果同一URL没有命中缓存，那么就会存在同一长URL映射出多个短URL的情况）（这是储空间和性能方面的折中）
3）如何保证分布式发号器每次发号一致：简单但细节需要考虑的方式：用Redis发号，比如有10个发号器，比如1发号器只发尾号是1 的……，那么当该发号器发号后，步长加10即可。（只是较简单的设计，还要考虑单点问题，那么肯定要引入Redis从节点，那么主节点挂了从节点开始发号，这时如果主从同步延迟，就会重复发号……，所以工程可用的方案还是参考：分布式发号器）