如果只是设计一个点赞接口，用来存储点赞数据，不做点赞列表功能，我们可以使用redis里的集合来实现，主要利用了集合的互斥性。

那么，我的想法是，点赞和取消点赞都是同一个接口吧？

逻辑是：

判断uid是否在集合中

是：则从集合删除，这个等于取消点赞

否：加入集合，这个等同于点赞

以上这个逻辑是不是要用lua脚本来运行，以保证其原子性，是吗？

否则我想了下，如果当前状态是未点赞，连续快速点击两次后，理论应该还是属于未点赞，但是如果不能保证原子性，则可能会出现连续点击两次后，结果为点赞成功，请问我以上的想法是否正确？

1. 点赞和取消点赞建议设置为2个接口，客户端所有的行为都当做是不可预测的，我们不能保证客户端显示的点赞状态和服务端实际的点赞状态一致(当然属于小概率事件)，分两个接口还有一个优点是在用户点击了“点赞”按钮后可能要等服务端返回点赞成功后才会使点赞按钮变色，这时如果是多次点击调用也应该是调用点赞接口，从而避免在网络不好的情况下用户体验不好的问题
2. 关于redis指令顺序的问题，只要保证后端代码送入redis的指令是顺序的即可，redis内部会保证指令按照顺序执行

redis lua 可以保证原子性，按照你的方案做也可以.
我们之前的设计实是两个接口来保证接口的幂等性，也是因为有点赞的地方我们是要先加载点赞状态才能继续操作的.如果你页面不加载点赞状态，就只能按照你的做法做，但是点赞动作页面需要做并发控制，一个点赞动作服务器还没响应，就不能触发第二个点赞，同时redis要保证两个来了之后，你的逻辑的原子性

我理解的是，你的方案可以实现，也没必要用lua实现原子性，用户连续点击两次，最后状态会变成未点赞状态，不会变成你说的“结果为点赞状态”
因为redis本身是单线程，连续点击两次就是连续顺序执行两条同样的命令，实际不会有并发的执行