风过孤屿，山海自成诗行。

竞态条件引发的数据一致性问题，其本质为多执行单元对共享资源的无序并发访问。核心解决思路是将并发操作串行化，主要通过悲观锁和乐观锁两种策略实现。悲观锁采用 “先锁后用” 的保守策略，通过获取锁来独占资源访问权，强制其他线程阻塞等待，常见实现包括单机环境下的 JavaSynchronized关键字、Go 的Mutex，以及分布式环境中的 Redis 和 Zookeeper 分布式锁。其本质是利用状态标记实现资源的独占控制。乐观锁秉持 “先操作，后验证” 的理念，允许线程先执行操作，通过版本号或时间戳校验...

分布式事务和单机事务非常类似，都需要去实现ACID特性。只不过，在分布式环境中，由于不可靠的网络和时钟，导致我们需要通过确认应答模式&重试机制来增加一些机制来实现事务的原子性。由于这些额外的机制，会导致性能的急剧下滑（全局锁&重试），所以我们常常为了平衡，会根据自己的业务场景去决策实现哪种程度的一致性（强一致性/顺序一致性/最终一致性）。

单机事务中的一致性问题，通过原子性、隔离性和持久性这三大特性的协同保障得以实现。原子性确保事务操作的完整性，避免部分成功部分失败的情况；隔离性控制并发事务之间的相互影响，通过不同的隔离级别和并发控制手段，实现数据访问的一致性；持久性则致力于将事务提交的数据可靠地存储到磁盘，在性能和可靠性之间寻求平衡。

fatcache是来自Twitter, 基于SSD上面实现的cache, 使用mc的协议，数据存储在SSD (Ps:memcached是将数据放在内存中)。 fatcache的数据放在SSD(其实机械盘也可以，只是性能不佳), 所以相对于内存cache, 如memcached、redis，能容纳更多数据。

前段时间一个老的系统重构项目上线，在这个过程中出现了很多问题，遂想针对在这个过程中遇到的一些问题和实践，记录总结一套系统重构的范式，并回顾反思在这个过程是否有哪些值得改进的地方。

Leveldb是一个持久化存储的KV系统。实际上，它就是我们平时说的底层存储引擎，或者说是一个数据库，我们平时所熟知的redis底层用到存储引擎rocketdb就是从leveldb上演化过来的。

lsm-tree是一个以优化写操作的存储策略，核心思路就是顺序写替换随机写。lsm-tree在传统磁盘上的读写性能表现非常出色，在工业界非常流行，比如腾讯tendis和360的pika底层用的rocketdb就是采用lsm-tree来实现的。但是随着时代的发展，SSD性能的提升和读写方式的变化，使得lsm-tree渐渐暴露出一些问题，也让我们不禁去探寻一种更为高效的存储方式。

KVELL是一种比较新的数据存储方案，该方案主要是针对近年来性能不断提升的SSD去设计的。其核心就是内存索引+非顺序存储。同时对于SSD还有一些优化，比如类似fatcache的Slab机制，底层批处理I/O，非共享设计等等。总之，KVELL是针对现代SSD存储设计的一种存储方案，某种程度上又回到了原始的读写方式（顺序读写->随机读写）。不得不感叹一句，设计的魅力在于权衡！

本文讨论了一致性中比较典型的两种场景——冗余数据存储&分布式共识决策中的一致性问题，并且根据总结了常见的解决范式，通过归纳，我们发现很多场景的解决思路非常相似，比如CPU多级缓存和redis-mysql的一致性问题，都是通过同步写+“读屏障”去解决冗余数据的一致性问题...

报警治理中context cancel报警凸显，通过探究go中context原理，结合业务实际使用场景，总结诱发场景和治理建议...

本文从概念、使用、原理探究以及思想，由浅入深地讲解了go的context包，同时阐述我自己的一些理解和思考。context本质的数据结构是一种多叉树，它和我们函数调用关系天然契合...