如题
最近同事遇到con-current使用者的问题
想找寻相关的书籍
处理这个同时多人上线系统的问题
遇到con-current使用者大约一秒有3~4万 ,
怎么从系统架构规划去处理这些问题
目前只有找到
下面连结的资料
http://www.slideshare.net/jserv/ticket-vending
如有不妥
小弟再删除这篇
感谢各位
auto scaling + loading balance
scale-out, architecture, cache
作者: Sieg2010 (Sieg) 2016-05-06 21:22:00
可以搜寻C10K
本版搜寻“宽宏售票”有一些优质文章；另外推荐“巨型网站，从成长到…”这本书另外可以google“stackoverflow architecture 2016”架构面，如果运算都在后端，可以长机器解决；瓶颈会在数据库没办法auto-scale，要不关掉升级硬件(贵在license)，要不大量做redis cache，或是简化sql、减少lock，相对风险就是有没有transaction考量
作者:
yyc1217 (somo)
2016-05-07 00:44:0012factor~
作者:
remmurds (Stronghold)
2016-05-07 14:35:00其实这类问题最终都会卡在 DB 那关application 的问题其实都好解决另外是concurrent 很少有人在说con-current
作者:
loseptt (loseptt)
2016-05-07 20:09:00用redis挡一下不要虐DB
作者:
drakd4d (NULL)
2016-05-07 20:36:00如果碰到写入就真的比较麻烦，如果只是读取memcached跟redis都可以解前面进来 lb 分给 application servers 就解决了
像售票系统或电商有库存控制这种不是长机器数量救可以解决的
作者:
GoalBased (Artificail Intelligence)
2016-05-08 01:10:00kktix ruby -> go
作者:
xxoo1122 (一个连IE6都能相容的男人)
2016-05-08 09:32:00我从硬件面来说，你可以参考Stack Overflow: The Hardware - 2016 Edition，你可以发现他的DB都是选用时脉较高的CPU，Ex:E5-2667，再来他选用Intel P3700 nvme的SSD，这颗SSD效能在400k IOPS。