Rails Rails 并发处理

bighuzi · 2017年03月03日 · 最后由 pathbox 回复于 2017年03月09日 · 13 次阅读

最近遇到一个项目。老系统是用java的。整点大概有6000 - 10000左右的样子做同一个操作。现在准备要用rails来重写这块的东西, 对于高并发的处理不是很懂。 希望能得到处理这方面的高人指点下迷津。感谢!

共收到 22 条回复

瞬间 6000 的请求?

huacnlee 回复

是的。。差不多就是这个数值吧。。在这个区间的样子。。。

并发取决于几个因素:

  1. 单个请求的时长
  2. 业务能接受的处理时间
  3. 有没有资源争夺
  4. 有多少硬件算力
bighuzi 回复

那你们老系统什么配置可以撑那么多?

同一个操作

什么操作?读还是写?是同一个数据还是不同数据?

huacnlee 回复

系统是负载的,有3太服务器跑。都是8核16g内存。。数据库另外的服务系统, 同一时间检索同一数据表做查询。。跟插入。。, 现在老系统已经不行了。。

单个的处理速度还是很快的。。

信息太少了,不同的业务场景差别巨大的,例如插入是插入什么是并发插入,还是个别的。

或者说那些并发具体是写什么东西。

同样的业务Java顶不住,换ruby只能加更多的服务器,虽然代码简洁但是成本并没有降低,Ruby处理这个场景没有比Java更好的性能优势和成本优势。

如果需要实时处理建议用golang重写或在Java基础上再优化,否则如果不需要实时可以考虑sidekiq golang版去处理

bighuzi 回复

不要认为说单个请求的响应足够快好了,并发的时候和你单个请求的时候完全不一样的,会有很多问题。

例如:

  1. 资源是有限的,你得有足够的机器处理能力
  2. 决定 Rails 应用程序吞吐量的是 (Response Time * 进程/线程数量)
  3. 并发来的时候,处理不当,造成锁,例如同时修改数据库一行的数据,同时修改一个文件等等

换框架,换语言不能解决你的问题,一样做不出来,你们需要一个有经验的架构师

先定位问题,才能解决问题,找到吞吐量上不去的瓶颈在哪里

这需求我觉得还是java靠谱,虽然最靠谱的是人。

无法满足要求,你们团队选型rails的人该被开除

rails 做到 10000 QPS 需要

  • 代码质量极高,
  • 一层一层的 cache,
  • 精简 gems and rails middleware
  • 以及对业务理解...
  • 外加 cdn 等护身法宝...

换rack + sequel吧, rails只能堆机器 + 各种优化来弥补性能上的损失

不要引入 active X系列 activemodel activerecord activesupport

太占内存,rails系列,随便一个进程150M+内存是无压力的,代码质量差点,跑的时间久点,内存是会涨的,300M,500M/进程 无压力。

查询加缓存

非必要实时写入(指你当前时段写入的数据,在本次并发查询【一定】不会用到),可以考虑做延迟写入; 如果DB是mysql,精通mysql的话,可以自己做binlog收集及批量导入,不精通就算了,风险指数略高。

rack + sequel + puma 多worker,在目前公司项目中,内存50M一个进程,几月稳定跑,进程不假死,内存固定不涨,不能说太多,说多了算是在黑Rails了。

zfjoy520 回复

😥 很僵硬。。很尴尬。

bighuzi 回复

是。没有代码示例确实有点枯燥

  • 办法一:可以考虑从业务上调整。整点同时6000并发,这不是人为操作,而是有程序在向你们服务器发请求。你们作为上游可以尝试让下游调整。
  • 办法二、如果下游不要求rails同步立即给出最终结果的话,可以把业务处理交给后台程序(via sidekiq, resque or RabbitMQ),然后快速响应下请求。
  • 办法三、用Node.js试试看,启用Cluster模式。
  • 办法四、找出瓶颈,就用原来的Java跑。
  • 办法五、8核16g内存这种服务器已经比较老了,建议更新下硬件(包括硬盘)。

这并发量真的大

用ruby不可行,用其它语言吧

何况你还不懂。。

zfjoy520 回复

这样想想,如果从语言和框架分析,干脆继续从java方向优化,性能也许比rack 要好。比如,用适应高并发的java框架。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册