#52 楼 @fsword 因为有微信了，讲师都在一个群里，要起来很省心。往年都是用 email 一封接着一封去追讨。

#44 楼 @alucardpj 当爹了。

请问你是在 DELL 工作的么？

#15 楼 @will7v 给你点个赞。

二维码在群人数 100 以内才可以扫码进入，现在只能让群里的人加群外的人好友，然后发送邀请加入群。

JRuby 可以解决这个问题，JRuby 没有 GIL，多线程情况下，JavaVM 会调度线程在不同的 CPU 核心上执行，关于是否出现灵异事件，建议你测试一下，你给出的信息不足以判断。

只要是在一个 Ruby VM 中运行的代码，在任何情况下，GIL 都保证了你的代码在同一个时间只能被一个 CPU 运行，如果你要用多核的话，需要看你的程序处理的任务能否分割，然后多进程的方式执行子任务。

#10 楼 @xiaoronglv 这套架构搞得定，没有问题。

曾经跟学姐讨论过这个话题，换个角度来说，如果是 Rails，产品用户数量超过一百万应该怎么搞？无非是优化单机的吞吐量，以及水平扩展。而学姐介绍的这套基于 Cuba 的架构，单机处理能力比 Rails 高一个数量级，水平扩展的方式却是一样的。

#32 楼 @juanito 没有问题

好大会其实没有不超时的，关键是接受程度，上座率，尿点比例，用事实来说明一切。

华顺把大家的茶歇时间干掉了，

明天让 RubyConfChina 2015 刷爆朋友圈的节奏么？

对 Web Service 不熟悉，话说 Web Service 这么 general 的名字被 Java 给带坏了。 如果返回结果不能映射成数值对象的话，那么你只能用解析 xml 字符串的方式处理返回结果了。 在网上搜一下如何用 Nogogiri 去解析 XML 吧。

#55 楼 @tony612 放上去了。

为炮神点赞！ :plus1: <= 我跟楼上不一样，我说点就真的点了。

RubyConfChina 历史上从未拒绝过没有票的人，如果想要参会买不到票，只要提早到现场购票都没有问题。

#41 楼 @chareice 能。

#10 楼 @tzwm 优惠的时间窗口是三天后，现在就发出来预热就是为了让你百爪挠心的呀！

验证码问题跟 Session 问题其实可以归类为一个问题，因为 Web 服务基于请求响应模式，在两次请求之间通过 Session 去保存临时状态，所以你的验证码状态可以通过 Session 来保存，而 Rails 为了可以水平扩张，默认使用 Cookie based 的 Session 保存机制，也就是说，Session 存储在 Cookie 中，Cookie 存储在客户端，客户端每次请求的 request 都会附带 Cookie 信息，在 server 端收到 cookie 然后还原出完整的 session，取得前一次请求中的验证码状态，这个机制刚刚好解决了你提出的验证码问题。

关于其他需要共享的状态信息，一般通过数据库或者其他持久化机制去保存。

第一个问题：unicorn 采用的是传统的 unix 多进程协作的方式处理请求，主进程负责接收请求，然后委托给子进程去处理，并且负责监控和管理子进程的状态，必要的时候可以 kill 并重启子进程。Ruby 1.9 以后开始支持 Copy-On-Write 模式，在这种模式下，fork 子进程的时候可以共享主进程的内存对象，而对象的写操作发生在子进程自己的内存空间，这样可以达到节约一部分内存的效果，比如避免子进程重复载入整个 Rails 的库对象。unicorn 的子进程之间没有进程间通信机制，各自独立处理请求，所以子进程之间不共享内存数据，但是可以通过其他方式去共享一些非内存数据，比如共享 Redis，数据库，或者文件系统中的数据。

第二个问题：Rails 4.0 之后默认开启线程安全模式，也就是说 Rails 可以跑在基于线程模式的 WebServer 比如 puma 上，以 puma 为例，派生出一个线程去处理每个请求（或者基于线程池），线程共享主进程的内存对象，但是处理请求过程中产生的新内存变量会存储在线程自己的栈帧中，基于线程模式的服务模型比基于进程模式更加节约内存，因为整个 Rails 是线程安全的，且 MRI 基于 GIL 全局锁模式保障多线程下内存变量访问的安全，所以基于同一个 Ruby VM 下的多线程模式的并发问题不是问题。

第三个问题：因为这个问题涉及到 Unix 的进程模型，线程模型，WebServer 的运行机制，以及 Ruby 本身的线程加锁的实现方式，以及 Rails 的线程安全策略（Rails 的 eager_loading 机制）等，是一个复合型问题，所以搜索资料的时候需要选取一个角度去搜索，但是本论坛充斥大量的相关讨论，建议多耐心深挖一下。

私货，在高并发方面，我推荐 @robbin 的几篇帖子，虽然写于两年前，但是结论已经概括完整且至今仍然适用。

https://ruby-china.org/topics/9851 https://ruby-china.org/topics/10832 https://ruby-china.org/topics/11249

深圳能否买到青岛啤酒，纯生的？

:plus1: :plus1: :plus1:

扫了一眼你的 Controller，你的 new 和 create 的实现为什么对调了？

:plus1: 置顶支持你。

#21 楼 @xiongmaojames 你能重新发个问题么，我觉得你的问题问题有点宽泛，让人不太好回答，如果重新问的话，建议把问题拆分以下，然后只要问题有价值，我保证这里会有人乐意回复你的。

这里不欺负新人，但是不欢迎伸手党。 请看一下这篇文章 https://ruby-china.org/topics/24325 请解释一下你的问题为什么找不到，到底你怎么找到的，以及你是如何理解问题本身的。

#35 楼 @betterthornbird 你又给我这个拖延癌晚期患者会心一击啊！

http://www.yaml.org/refcard.html

'<<' : Merge keys from another mapping.

用 rake task 去检查 sidekiq 的运行状态不是不可以，只是不应该通过 processes_size 去检查，而应该根据 sidekiq 的进程号去检查，判断进程状态，失败则重启。

sidekiq 会意外退出，如果不是系统资源不足或者第三方依赖问题（比如 redis 挂掉，或者通讯问题）等，相当于给了你一个信号，系统里存在坑，如果不及时排查解决，定时检查重启 sidekiq 其实是治标不治本。

关于正确的 sidekiq 进程监控和管理，正确的姿势其实是用系统自带的进程管理器，比如 Ubuntu 自带的 upstart 或者更超前的 systemd 来管理进程，具体细节，sidekiq 的作者在 Blog 有一篇文章专门解释过。

http://www.mikeperham.com/2015/07/16/sidekiq-and-upstart/