https://segmentfault.com/a/11...
url后面的1190000000490733是怎么实现的，以及这种方式的好处
https://segmentfault.com/a/11...
url后面的1190000000490733是怎么实现的，以及这种方式的好处
这才是你要的答案
http://segmentfault.com/q/1010000000142374
以下答案全是猜测，如有雷同，纯属巧合！
有一个类似全局发号器的服务，按固定的系统规则进行发号
前三位是预留的给系统模块用标识符，比如101是问答，119是文章，笔记是133，职位是128，活动是116，收藏夹是123等等或许还有其他模块
然后后面13位相当于预留了万亿数据量，对系统内产生的所有模块所有数据统一做自增
好处是：
1.方便数据库按模块分库、分表、分布式等部署
2.方便进行服务化架构
3.给递归采集全栈数据一定的门槛
4.隐藏某个模块的实际数据量
5.通过ID前三位快速知道这个数据属于哪个模块
6.应该还有...
a应该代表article，你这个网址就代表查看ID为1190000000490733的文章。这种ID是有一些随机生成规则的，目的就是防止用户去猜，防止爬虫去抓。你要是1,2,3,4,5这种整数连着往后排，别人就好猜了
很像RESTful接口，读读RESTful API 设计指南这篇文章就知道RESTful规范的好处了，更合理地使用了http动作，让接口变得很清晰。
至于实现方式，只要保证生成唯一id就可以实现了吧。
可以使用mysql的uuid_short这个函数生成uuid。当然sf也可以自己定制规则或者使用php的生成uuid的函数实现。
测试了一下，发现这个id是不连续的。猜测应该是一个支持分部署的id生成服务生成的id。
<code>https://segmentfault.com/a/1190000000490733 https://segmentfault.com/q/1010000006600460</code>
文章；问题；评论估计都是用的这一个id生成服务，所以，直接将某个id+1，是访问不到数据的。
之所以使用这种分布式的id生成器，是
