要具体看协议了。比如直接读 16 位，有哪几位是长度啥的。 既然用 protobuf 了，为啥不直接 grpc 呢？

在南京啊（过来捣个乱

rairoady 了解下？

这种场景 erlang 更合适吧？直接起 erlang 的 process，timeout，分布式，内存回收，服务发现，都自己就带了。

有些常用的命令可以用啊，很方便的。

哭啊。。。

公司买了企业级路由、开了专线，找专人调网络。有的时候，网络还是不好。。。。

抢购 的请求都是 GET？没更新数据库吗？

猜一下，都是更新操作，上了锁，然后释放慢了？callback 里有什么耗时的操作？或者 counter cache 之类的被锁了？

Clojure 了解下。

下划线、中划线、驼峰。。。

执行中的任务会丢吧？

阻塞怎么回事

假设一个请求，需要 2 秒，那这 2 秒，耗时在哪？

一个 request 的大体流程，三次握手，发请求，接收请求，关闭连接。

CPU、内存的操作，速度都很快，不需要考虑。

我们单独考虑请求发出去，等待放回这个过程。

请求已经被发出去，IO#read 读数据，由于数据还没从服务器返回，一直等数据返回后，才能读到数据，在等待数据返回这段时间，process 什么也没做的（被挂起了），所以是一个阻塞操作。

就好比，你要一个人帮忙买东西，你跟这个人说，帮忙买 A，然后你就睡觉了。A 回来的时候，上帝（操作系统）会再叫醒你。

如果想高效一点，很自然的可以让多个人同时去买，然后让他们把买好的东西放到一张桌子上，你时长去检查，桌子上有没有东西就可以了。这样就从，同一时间买一样东西变成了同一时间买多样东西。

你在系统中就是线程，跑腿的就是一个 IO 对象，检查桌子上是否有东西，就是 IO#select 操作。

这个 IO 模型就是 IO 多路复用。

只是请求吗？可以考虑丢 ruby 的线程里。只是请求的话，本地跑到 1k/s 还是可以的。

不过这个场景，用 nio 更合适些。线程毕竟耗资源。

这种场景，go 也是要上 nio 吧？

最后还是 erlang 大法好！

解释器，先把字符串读到语法树中，之后对语法书进行求值 (evaluate)。 比如 a = 1; a + 1; eval 到 "a + 1" 的时候，需要知道 a 的值是什么，所以需要存 a = 1 这个信息，这个就是 context。

Ruby 是 Lexical Scope，每一个方法，都是一个新的 scope，所以需要一个新的 context 来做存储（全局变量啥的，先不考虑）。

比如：

def foo(a)
  a
end

eval("foo(1)")，需要记录 a 的值。

如果 foo 里面出现了递归，

def foo(a)
  a + foo(a + 1)
end

首先会把 a 这个变量存到上下文理，然后 eval("foo(a + 1)")，由于上下文一直增长，所以造成了栈溢出。

而尾递归是这种递归

def foo(a)
  foo(a + 1)
end

可以不需要存储上下文，所以不会有栈溢出。

emacs 的 magit 算 git 的 GUI 吗？

连的是同一个 redis 吗？

再提供个思路，用 Concurrent::TimerTask，actioncable 用的是这个。 ActionCable::Channel::PeriodicTimers 提供了 periodically :transmit_progress, every: 5.seconds 这样的语法糖。

web usb

有一个项目还真的用了不少数学知识，不过现在野忘了…

用 exists? 感觉会好一些。

exists? 语义化，而且会快些（我测的）。

记得实现大体是，根据 primary key 做排序，取数据的条件是，要大于上一次取得的最后一个 primary key，limit 是给的 size 参数。

应该是可以用来做删除的？

哦，还有排序。。。要试试看才知道了。。。

用 find_in_batches ?

或缺少的？

timers

利用 current-ruby 的 Concurrent::ScheduledTask，activejob 的 async_adapter 用的就是这个。

jruby 的话，有 TimerTask

不过我没做过测试，不知道这些解决方案的精准度、容错之类的怎么样。

不考虑性能，ruby 写数学方面的东西，也不见得有优势。机器学习的语言，需要的是数学语言，而不是自然语言。R 也慢，但用的人还是很多，一部分原因是它的语法适合。

ruby 不单单是没有优化的问题，面向对象本身就快不起来。

没有没有，我就是随便搞搞。

我还有一些问题没搞清楚

哈，已经有两个主题了 下次活动预约个 nio 优化网络请求的主题。

看了一遍Strikingly 团队 2017 技术展望，粉丝面圣式跪求微服务方面的分享。

微服务应该有好多东西要做。。。通信、拆分、分布迁移啥的。。。RoR 似乎不是很赞同微服务，ActionCable 直接 load 了一个 app，这种感觉也挺好的。