@codeismylife 那要不就新写到新表里，全部做完之后统一合并之后批量更新，如果字段值占用字节数不变，批量更新估计也不慢

@maxiaofeng #3 加两个字段不还是更新操作么？这种情况就要把更新操作变成批量写才快啊

如果结果只是需要统计展示的话，最快的应该是再加两个表，一个存是否出去，一个存是否发送，把更新操作变成批量写是最快的了吧，到时再联表查一下就出来了

支付宝和微信都有延时重试策略，几乎不会出现挂的情况，其他的支付方式可能通知不是很严谨，但是用户量小的话几乎可以忽略了吧，能用就是了，三天就搞出来的还想咋滴了

感觉上简单来说就是早年间 idc 网络都是人工一台一台路由交换机设置的，子网也是人工划分好的，后来设备太多了，几万几十万的，弄不过来了，特别是云起来后，好吧，那我写个软件统一控制吧，统一规划网络吧，sdn 估计就是这东西

后来则有了更多的需求，比如云各账号网络隔离啊，网络和链路自动迁移，网络负载自动均衡，等等啥的似乎都可以很简单的都过这东西解决了，所以也就越发复杂了

https://github.com/snower/forsun

推荐下之前写的工具，支持秒级定时，命令行和 crontab 类似

安装
pip install forsun

启动
forsund

设置定时
forsun "set show_date_to_home */50/0 * * * * * sh 'date >> /tmp/date.log'"

查看定时列表
forsun "ls *"

删除定时
forsun "rm show_date_to_home"

时间设置还是多了第三个数字代表的是执行次数，0 代表一直执行，从设置这一刻往后 50 秒运行

@reus #38 好吧，我对 go vet 不太熟，这地方也不是核心锁，所以没注意到了，现在学习到了，已经修改过来了，感谢

@wusatosi #35
@index90 #39
首先我们认为能够使用外部锁同步的，应该是极其短时且大量相关性不高事件，所以冲突概率不高，其次就算冲突，底层应该还有事物或是 raft 这样的一致性协议保证最终一致性，所以不会造成太大问题，我想已经有很多论文证明过通过一个外部锁解决一致性问题是不可能的，更别说通过外部锁解决外部系统一致性问题更不可能，所以这里同样无法解决

但是即使如此，外部锁仍有其意义
在大型系统中，raft 这样的协议解决冲突非常复杂消耗资源，更别说微服务场景中，一致性的产生更加复杂，如果外部锁某些时候确实可以消减一部分的冲突，对系统性能改善或许是有意义的，更别说在平滑系统负载，抗冲击都是有一定的意义

而在大量的中小型系统中，几乎都是短时任务的场景下，本身系统负载就低，遇到奔溃的几率本身就微乎其微，在复杂度开发周期成本考量下，我想这只是一个工程抉择问题，而且大量单机 redis 场景下，过于考虑高可用其实意义不大吧

从其他来说，操作系统提供的锁，除了 Lock 还有 Event 和 Semaphore 的吧，以往很多时候我们都用轮询、订阅或是队列来解决这两个问题了，但是在简单场景中，这确实有些复杂，能购用更简单的 Event 和 Semaphore 语义来解决这个问题又有什么不好呢

总的来说，这其实是一个工程问题，不是学术，更不是一个可以通用的解决方案，在工程中，我们有更多考量，过往积累，实现周期复杂度，成本，维护性等等，所以是否有用还是看整体系统方案，比如云，难道没有单点问题，不会有崩溃不一致问题么，我想事实不可能，但是我们综合考量，确实是最好的

只是个方案，大家仁者见仁，智者见智就好了，这不是一个通用解决方案，也不是一个学士问题

什么刷脸支付，什么刷脸取件，去年感觉还有点高端未来，怎么今年感觉这么傻叉呢，特别讨厌这种功能，看来没前途

@aleung #30 那可能是有歧义，没说给分布式系统用的锁，你说的对，锁服务

@reus #31 玩一下，要啥测试啊，麻烦死了
协议没有用 binary 包，这是故意的，binary 包内部用了反射，性能很差
至于正确性，正确运行就是正确性

@lhx2008 #27 走 tcp 啊，不是单机的库，啥意思？

@wweir #23 我知道啊，这难道不是用一致性来解决同步问题么，所以核心还是一致性啊
这里不是主要讲数据同步，更多是即时状态同步

@aleung #22 对对对，就是这个意思

@lhx2008 #21 首先 redis 锁没有 wait。。都是延时重试

@wweir #18 paxos、raft 解决的是一致性问题吧

@pifuant #15 不过最近也在考虑也行可以加入 binlog 和集群模式看看，也只是探讨，在很多小微场景确实高可用不是特别突出，简单快速解决问题也挺好不是

@pifuant #15 本来就是小工具啊，解决小微场景中某些用锁可以很方便解决的同步问题，并没有说在大型场景中可以很成熟使用

@wusatosi #14 同步问题中不是特别怕中心挂的情况吧

一般来说同步场景都是某一刻同步，比如 a 和 b 在前一刻用 1 中心同步，那么 c 和 d 为啥不能在下一刻用 2 备用中心同步呢，其中产生的一致性问题应该仍然还是由数据库事物或者其他一致性协议来保证

总的来说，分布式锁其中一个场景应该是想要解决的问题应该是我们在很多时候使用一致性结果来同步的极大资源消耗问题，比如很明显的秒杀场景中，是否还有库存这个状态

其他的比如扫码登陆时，是否已经扫码不也是一个同步问题么