如題
最近同事遇到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。