使用TiKV可以实现Redis的incrby并保证原子操作吗?

我现在使用Redis,想使用TiKV替换现有的Redis,但是其中我使用了Redis的incrby的原子性,作为分布式锁,来保证同一时间,只有一个线程操作临界资源,想问问,这个原子性的incrby,是否也可以使用TiKV来完成,达到使用Redis同样的效果呢?谢谢

PS:我现在使用Tidis来访问TiKV。

嗯, redis 的原子性 和 tikv 提供的事务性支持,具体的表现上还是不一样

redis 依靠单线程的队列模式,保证同一时间只有一个资源可以调度和执行
tikv 需要依靠一些机制来满足这个要求,本身是可以支持原子性的,因为原子性的上层是事务性。
主要 tikv 是多个节点的,然后数据是可以分散到不同节点上的
redis ,是依靠 slot 算法,来找到 点位和节点,来进行读取的(集群模式)

所以你想使用 tikv 来实现 redis 的 分布式锁,则需要自己实现一些其他的功能了

您在最后一句提到

能具体说说是什么功能吗?我猜测:由于tikv是多个节点的,因此需要自己在应用中实现类似原生redis的单线程队列模式,以我现在使用tidis作为中间件来考虑,可以在tidis实现这些功能,对吗?

不知道中间件是否能满足你的需求,如果能满足的话,,没多大问题

PingCAP官方Tidis暂时还未开源,预计下周会open,敬请关注。

Tidis目前实现了incrby命令,语义上也可以保证原子性,但是在高并发修改同一个key的情况下可能会出现事务冲突,然后会自动重试,这种极端场景需要在具体场景下验证。

非常期待!

这很有挑战,但是不严格测试,就担心生产中赶上极端情况!

只要业务对错误返回能够容忍,并且有重试逻辑就ok。

嗯,重试逻辑,值得重点考虑,另外,将redis的单线程思想,放在Tidis中,制作一个特定的自用版本,也是一个可行的方法吧?

我觉得完全可以使用TiDB实现分布式锁啊。
基于数据库实现分布式锁。
select for update方式就可以实现啊。
又会分为乐观锁和悲观锁模式,看自己应用的容忍度,自己实现啊。

悲观锁:利用select … where … for update 排他锁
乐观锁:通过增加递增的版本号字段实现乐观锁

我现在的主要考虑,还是用TiKV替换我现在的Redis,TiDB替换Redis,可能未来会考虑。
但是,你提到TiDB做分布式锁,到时候倒可以参考一下思路:smile:

利用数据库特性就可以实现。现在肯定也有数据库使用的,搞一张表,封装一个api应该就可以了。

开源啦 https://github.com/tidb-incubator/tidis

收到,马上下下来测试一下,先贡献一颗星^_^

any update?