我现在使用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做分布式锁，到时候倒可以参考一下思路
利用数据库特性就可以实现。现在肯定也有数据库使用的，搞一张表，封装一个api应该就可以了。
收到，马上下下来测试一下，先贡献一颗星^_^
any update?
update what?
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。