作者yuanyu90221 (菜菜鳥)
看板Soft_Job
標題[請益]關於con-current使用者的書籍
時間Fri May 6 21:14:30 2016
如題
最近同事遇到con-current使用者的問題
想找尋相關的書籍
處理這個同時多人上線系統的問題
遇到con-current使用者大約一秒有3~4萬 ,
怎麼從系統架構規劃去處理這些問題
目前只有找到
下面連結的資料
http://www.slideshare.net/jserv/ticket-vending
如有不妥
小弟再刪除這篇
感謝各位
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 203.187.32.102
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1462540474.A.389.html
1F：推 rayway30419: auto scaling + loading balance 05/06 21:20
2F：推 landlord: scale-out, architecture, cache 05/06 21:21
3F：推 Sieg2010: 可以搜尋C10K 05/06 21:22
4F：→ yuanyu90221: 感謝大家~ 我來去試試 05/06 21:25
5F：推 sing10407: 本版搜尋「寬宏售票」有一些優質文章；另外推薦「巨型 05/06 21:45
6F：→ sing10407: 網站，從成長到…」這本書 05/06 21:45
7F：→ sing10407: 另外可以google「stackoverflow architecture 2016」 05/06 21:46
8F：推 sing10407: 架構面，如果運算都在後端，可以長機器解決；瓶頸會在 05/06 21:56
9F：→ sing10407: 資料庫沒辦法auto-scale，要不關掉升級硬體(貴在licens 05/06 21:56
10F：→ sing10407: e)，要不大量做redis cache，或是簡化sql、減少lock， 05/06 21:56
11F：→ sing10407: 相對風險就是有沒有transaction考量 05/06 21:56
12F：→ yuanyu90221: 感謝 05/06 22:07
13F：推 yyc1217: 12factor~ 05/07 00:44
14F：→ remmurds: 其實這類問題最終都會卡在 DB 那關 05/07 14:35
15F：→ remmurds: application 的問題其實都好解決 05/07 14:35
16F：→ remmurds: 另外是concurrent 很少有人在說con-current 05/07 14:52
17F：→ loseptt: 用redis擋一下 05/07 20:09
18F：→ loseptt: 不要虐DB 05/07 20:09
19F：推 drakd4d: 如果碰到寫入就真的比較麻煩，如果只是讀取 05/07 20:36
20F：→ drakd4d: memcached跟redis都可以解 05/07 20:36
21F：→ drakd4d: 前面進來 lb 分給 application servers 就解決了 05/07 20:38
22F：推 Deltaguita: 像售票系統或電商有庫存控制這種不是長機器數量救可以 05/07 20:45
23F：→ Deltaguita: 解決的 05/07 20:45
24F：→ yuanyu90221: 感謝大家的分享 05/07 23:13
25F：→ GoalBased: kktix ruby -> go 05/08 01:10
26F：推 xxoo1122: 我從硬體面來說，你可以參考Stack Overflow: The Hardwa 05/08 09:32
27F：→ xxoo1122: re - 2016 Edition，你可以發現他的DB都是選用時脈較高 05/08 09:32
28F：→ xxoo1122: 的CPU，Ex:E5-2667，再來他選用Intel P3700 nvme的SSD， 05/08 09:32
29F：→ xxoo1122: 這顆SSD效能在400k IOPS。 05/08 09:32