https://github.com/qichengzx/seqsvr
之前按携程的文章实现过一个递增的计数器，应该可以满足。

正在写一个基于 RESP 协议的存储中间件。我的 Redis 故事就靠这本书了。

买过这个。设置价格提醒到 200 以下，199 买到的。有加厚的隔层放电脑。
https://item.jd.com/653138.html

顺路安利下
Golang 中文博客文章阅读列表 https://github.com/qichengzx/gopher-reading-list-zh_CN

顺势安利一波：Go 实现的高性能全局唯一序列号生成服务 https://github.com/qichengzx/seqsvr
思路来自：干货 | 分布式架构系统生成全局唯一序列号的一个思路 https://mp.weixin.qq.com/s/F7WTNeC3OUr76sZARtqRjw

求 star。

https://github.com/qichengzx/sshh
another one

搭车安利一下
https://github.com/qichengzx/qcloudsms_go
腾讯云短信 Golang sdk

@zhouquan03 服务挂掉重启后，会从数据库重新写一条记录拿到一个新的 ID 做起点。

@pathbox
感谢回复。

关于 Redis 的 incr，原文中也有提到。优缺点引用如下：
优点：
不依赖于数据库，灵活方便，且性能优于数据库。
数字 ID 天然排序，对分页或者需要排序的结果很有帮助。
使用 Redis 集群也可以防止单点故障的问题。

缺点：

如果系统中没有 Redis，还需要引入新的组件，增加系统复杂度。
需要编码和配置的工作量比较大，多环境运维很麻烦，
在开始时，程序实例负载到哪个 redis 实例一旦确定好，未来很难做修改。

@glacer
感谢回复。
没有接触过分布式的系统，至少没有参与过。
写这个的初衷是看到携程的那篇文章，觉得这种方案还挺有意思的，就找时间做了实现，至于实际的使用场景，目前我确实不清楚。
根据文章的介绍，携程是用在了账号系统中。
个人觉得比如 MongoDB，没有数字 ID 的系统中，如果要用到数字 ID，这种方案也是适合的。

@wych
感谢回复。
是单调递增的。

@puritania
感谢回复。
1.可以单独部署成一个服务，也可以整理成一个包放到已有项目中。项目目前只是以独立服务作为实现。
2.MySQL 的问题，如果请求量不是特别大应该还好。业务量大也可以通过修改步长或 MySQL 增加机器解决。
3.根据携程的介绍是 Java 版使用情况还不错，而且个人认为 Go 的协程开销应该比 Java 低很多。

这个方案与 snowflake 相比，个人觉得原理和实现都比较简单，适合比较初期的项目。

有说的不对的还请指正。

@lex 感谢提供建议。

@Lihz 参考其他语言版本写的，没严格验证，我会改进下。

@zado 目前工作用到的直接存了高德的坐标，web 和 APP 端也用了高德地图来做。不知道大厂都是怎么用的。
应该还是看实际的各端用了哪家的方案吧。

正好在负责公司的对内服务的短信业务功能。
说说自己的一点经验。

1.号码有效性检测是必不可少，甚至可以说不需要说的限制。
2.对单一手机号的频率验证，如 10 分钟内只能发送一条，1 天只能发送 10 条。
3.结合 2，根据业务类型，对频率的限制，如果是营销短信，一般情况是群发，可以忽略其中每个手机号（一段时间内）的频率。
4.短信运营商（阿里，腾讯等）一般也会有多重限制，分钟级，小时级，天级的限制。
5.特定的业务，只允许特定时间段发送短信。


如 3 楼所说，验证 IP 容易误伤。特别是如果是某种线下活动，用户聚集在一个地方同时请求短信，IP 很可能只有几个，甚至只有 1 个。

另外，频率校验还需要考虑并发的情况。

最后，私心的打个广告，前几天刚刚完成的腾讯云 Go 语言 SDK，还有不足，请多多指教。

(qcloudsms Go SDK)[https://github.com/qichengzx/qcloudsms_go]