利用一个只能append的数据库(hive这种) 来存储所有的action, 认为这些action是按照时间序列进来的, 并且不会改变. 通过这些日志来维护整个服务的一致性
问题
很多服务如不开启bin-log的mysql实际上是只维护系统的当前状态, 一致性也局限在一个action这一步上.
解决
ext系列日志文件系统, mysql的bin-log了解一下.
日志系统都是非常类似的, 以ext系列为例, 对文件的增删改查都会首先计入到磁盘的一个日志区. 因为这些操作是不会改变且严格到达时间发生的, 所以可以顺序的写入到一个头部扇区里并不需要去考虑改写问题.
积累到一定程度的时候就可以把根据日志, 把操作刷到真正的数据持久化里去. 回滚时也可以按照日志来进行回滚操作保证了数据的一致性. 甚至玩意数据丢失了, 还可以通过重播这一段日志进行找回.
image.png
决策
- 从action达到, 到实际数据刷新有一个时间窗口. 这个时候读操作是否需要读一个已经跑了所有的action的一个snapshot? 又或者更简单一点, 幻读是允许的?
- 在多线程情况下, 操作的先后顺序对结果可能产生影响. 由于一般认为所有的action是保序刷到一个临时存储里的, 那么action的顺序应该如何来控制? 这里乐观锁了解一下, snowflake也是经典方案, 还有先把数据切成多个segment, segment内部有序, 相互之间无序等等好多种解决思路
- 日志系统可以在产生conflict前检查到conflict, 但是只有应该执行什么操作? 这里需要有一个执行策略
- 如果日志有可能被play好多次, 那么action必须幂等以保证最终一致性. 或者通过某种策略保证日志play only once