作者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/cn.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