关于key加锁的问题

[jianqingdu]

在PikaClientConn::DoCmd()里面：

1. 只有写入的时候，才会对key加锁，这样对于复杂结构，如果在读取一个list的中间，其他线程对这个key有写入，这样读取的时候应该也会出错
2. 只对第一个key加锁，这样对于多个key的操作，比如mget，mset等，其实是有问题的
   不知道我理解的对不对

[KernelMaker]

1. list的修改一般都会将对引擎的多次写入操作合并在一个batch里来保证原子性，所以不会影响到读取的正确性
2. mset这种kv的操作，其实都不需要加锁保护的，底下也是通过batch来保证原子性的

[jianqingdu]

batch只是保证写入的原子性

1. list的读取会有多次read操作，比如读取第一个元素，读取第二个元素，这时另一个线程通过batch操作修改了这个list，这时读取线程读取第三个元素时，是不是会有问题
2. 对于replication会有问题，比如两个线程同时操作，一个线程mset k1 v1 k2 v2, 另一个线程set k2 v3,
   由于写入只对第一个key加锁，所以两个线程都能同时写入，这时可能会出现以下顺序的情况导致主备的k2值不一致:
   mset k1 v1 k2 v2
   set k2 v3
   binlog set k2 v3
   binlog mset k1 v1 k2 v2

[KernelMaker]

1. 看了下代码，list读取接口中的多次get操作之间的确会因为一个batch写而不一致，这里可以改成读取接口都是基于snapshot来做，这样在保证一致的同时性能也会比读写相互抢锁的性能要高一些
2. 嗯是的，nemo里的行锁主要就是为了保护写db和binlog的原子性，当时考虑过对于kv接口的多keys写入操作该如何加锁，后来我们权衡当时开发成本和线上需要，就统一按照只对第一个key加锁

目前pika用的nemo库已经很老了，很多设计和实现都不是很优，开发完双主和pika_hub之后，我们后重头设计实现nemo，到时候再一起解决你反馈的这个问题，目前就先维持现状吧，anyway，感谢反馈:-)

[baotiao]

@jianqingdu 看的挺细的, 有时间一起和我们优化 nemo

[jianqingdu]

@baotiao pika感觉依赖的东西太多了，看着和编译都比较复杂，我自己也做了一个用RocksDB做存储引擎，兼容Redis协议的kv存储服务，相比pika：

1. 支持多db号
2. zset的score支持double类型
3. 不同数据类型的key不允许重复
4. 只依赖RocksDB库，编译比较简单
5. 比较完善的Tcl测试脚本支持
   地址是: https://github.com/jianqingdu/kedis

[KernelMaker]

@jianqingdu 赞👍，pika之所以依赖这么多库（pink，nemo，slash，nemo-rocksdb）是因为这些库是在我们平时开发过程中整理总结出来的，我们很多其他的项目也在用。可读性肯定没有全部写在pika中好，不过为了复用，这只能这样。

你的kedis我简单扫了下，实现的很棒，不过expire采用和redis一样的实现，通过线程去不断扫再删除会加剧引擎的写放大问题。另外想问下你多数据结构的删除和过期是怎么做的呢？

近期我们在考虑重构我们的多数据结构库nemo，解决已知的问题并优化性能
欢迎交流

[jianqingdu]

历史包袱的问题是比较纠结

通过线程扫描删除TTL超时的key确实会有写放大的问题，不过如果不去改RocksDB的实现，也就只能这么干了

对于复杂数据结构，都有一个对应到RocksDB的元数据键值对，值里面有数据类型，ttl值和元素个数，然后每个元素对应到RocksDB的键值对的键里面，是以数据类型，真实key 开头，所以要删除时，用一个迭代器就可以遍历一个key下的所有元素，然后用WriteBatch原子删除，RocksDB有DeleteRange()接口，不过看那个接口的注释，是一个实验性质的性能优化，所有没敢用，所以如果复杂数据类型的元素个数很多的时候，有可以直接把写入的IO打满

复杂数据结构的过期实现和string类型一样，有一个特殊的TTL数据类型，里面按TTL排序，还有一些信息表示这个key是哪个类型，然后有个独立的线程会去遍历这个前缀，直到TTL值大于当前时间为止，然后删除那些到期的key

[Coneboy-k]

@jianqingdu 写放大问题，可以放入凌晨这个时间段来进行操作。类似方案可以参考下日志型mq系统的实现。 kedis 中的 ttl 设计很赞，但我有个疑问，出于什么考虑，meta key 不加上version 号？ pika的version 可以做到秒删，这个很赞的处理。

[fancy-rabbit]

第一个问题，目前的实现似乎读取已经通过 Snapshot 实现了
第二个问题，blackwidow 实现里对所有 key 加了锁，但是 pika_client_conn.cc 里仍然还是第一个 key

[AlexStocks]

关于 Blackwidow 对 key 加锁问题：

如下两幅图，blackwidow 只对写加锁，对读不加锁，是否有脏读的嫌疑？

对此，二代目解释如下：

如上图，不会有脏读问题， Get操作使用的是default_read_options_, snapshot是nullptr, 所以是调用时刻的隐式快照。

像LRange这种读多个数据的， 虽然没有上读锁， 但是在读取之前会显式获取一下调用时候的快照， 然后后面读操作都用这个快照去读， 所以是一致的。

总结：

Pika 跟 mysql 默认的隔离级别一样，都是快照读，可做到 可重复读。