[請益]關於con-current使用者的書籍

[yuanyu90221 (菜菜鳥)]

如題

最近同事遇到con-current使用者的問題

想找尋相關的書籍

處理這個同時多人上線系統的問題

遇到con-current使用者大約一秒有3~4萬 ,

怎麼從系統架構規劃去處理這些問題

目前只有找到

下面連結的資料

http://www.slideshare.net/jserv/ticket-vending

如有不妥

小弟再刪除這篇

感謝各位

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 203.187.32.102
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462540474.A.389.html
推 rayway30419: auto scaling + loading balance
推 landlord: scale-out, architecture, cache
推 Sieg2010: 可以搜尋C10K
→ yuanyu90221: 感謝大家~ 我來去試試
推 sing10407: 本版搜尋「寬宏售票」有一些優質文章；另外推薦「巨型
→ sing10407: 網站，從成長到…」這本書
→ sing10407: 另外可以google「stackoverflow architecture 2016」
推 sing10407: 架構面，如果運算都在後端，可以長機器解決；瓶頸會在
→ sing10407: 資料庫沒辦法auto-scale，要不關掉升級硬體(貴在licens
→ sing10407: e)，要不大量做redis cache，或是簡化sql、減少lock，
→ sing10407: 相對風險就是有沒有transaction考量
→ yuanyu90221: 感謝
推 yyc1217: 12factor~
→ remmurds: 其實這類問題最終都會卡在 DB 那關
→ remmurds: application 的問題其實都好解決
→ remmurds: 另外是concurrent 很少有人在說con-current
→ loseptt: 用redis擋一下
→ loseptt: 不要虐DB
推 drakd4d: 如果碰到寫入就真的比較麻煩，如果只是讀取
→ drakd4d: memcached跟redis都可以解
→ drakd4d: 前面進來 lb 分給 application servers 就解決了
推 Deltaguita: 像售票系統或電商有庫存控制這種不是長機器數量救可以
→ Deltaguita: 解決的
→ yuanyu90221: 感謝大家的分享
→ GoalBased: kktix ruby -> go
推 xxoo1122: 我從硬體面來說，你可以參考Stack Overflow: The Hardwa
→ xxoo1122: re - 2016 Edition，你可以發現他的DB都是選用時脈較高
→ xxoo1122: 的CPU，Ex:E5-2667，再來他選用Intel P3700 nvme的SSD，
→ xxoo1122: 這顆SSD效能在400k IOPS。