问题现象

这几天遇到一个问题,用相同的索引(offset,length)从同一个文件fd中读取一段数据,通过CRC校验值发现偶尔有读错的情况:读到的期望CRC校验值与根据所读到数据算出来的校验值有出入,从读到数据来看,有时刚好错位了4个Bytes。

问题分析

分析日志发现竟然有多个线程并发读同一个文件fd的操作,之前设计读时没有考虑支持并发读的场景,因此也没有加锁互斥,但是Redo时的日志读与业务异步刷盘队列满之后不断重试的日志读产生了并发干扰。

根据索引到日志文件中读日志实际上有两个步骤:(1) seek到offset位置;(2) read指定长度的数据。这两个步骤无法保证原子性。上面的问题可以肯定是由于多线程seek产生了干扰导致读到非预期的数据。

阅读更多

背景
最近遇到一个问题,现象是主备反复倒换(产品的一个测试场景,对应到进程内多个线程反复起停),进程内存占用持续上涨直到系统OOM。


从操作步骤及现象来看,第一感觉是有内存泄漏,但内存相关问题定位一般都比较棘手。可能由于近期代码做了比较大变动(日志优化),虽然无法确认是近期优化引入的问题,临近版本过点,压力还是蛮大。经过几天的不懈努力,问题也得以分析清楚,期间把内存相关知识又过了一遍,收获还是蛮大的,记录一下。

分析思路:

背景
作为合作方与公司某基础设施部门合作,为分布式配置数据库提供数据一致性保证,随该中间件交付多个产品,时间长达两年。目前合作还在继续,多个产品版本不断迭代。


Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品。
关于一致性算法的应用场景,@Tim Yang在博文Paxos在大型系统中常见的应用场景有详细的总结,个人理解数据一致性保证的根基是带Commit语义的日志的一致性。 ,数据的一致性基于快照以及日志重放来保证,像 ZooKeeper™ 就是这么做的,和传统数据库由Write-Ahead Log机制来保证事物的原理是类似的。

一致性算法

方案设计(概述)

当初做设计时调研了无主的 e-Paxos(Github)、广泛应用的ZooKeeper™、以及当时刚被RedHat收购的Ceph/Monitors and Paxos, a chat with Joao Ceph,还有一个就是某个产品已经实现的一个方案,看了源码,可以认为是Ceph Monitor的C语言版本,但是实现的比较拙劣,性能比较差,这个后面再讲。
通过几番与合作部门沟通, 确定最终的方案为优化的Multi-Paxos有主方案,但是选主业务要求来做坑,后来的实践证明,这是一个严重失误,不做选主产生了很多问题)。

阅读更多