怎样去做 benchmark

要看你们的场景是什么样了，同时在线有多少人，大约会有多少 qps。然后写脚本，模拟这些连接和请求。

至于 4 台行不行，还得压压看。

看这个 https://github.com/anycable/anycable/blob/master/benchmarks/2018-10-27.md 压测，

8c15g 20k 的连接。

go 的结果是这个， clients: 20000 95per-rtt: 2892ms min-rtt: 3ms median-rtt: 399ms max-rtt: 4639ms

没找到具体的压测脚本，不知道是怎么发压的。

不过中位和最大 rtt，差这么多，感觉有问题啊。。。

而且 20k 的延迟有 5s，性能感觉也堪忧啊。

好久没用了。。。用起来还是挺流畅的。不过 ror 可以根据 model 生成 ERB。

ActiveRecord 至少可以解决 99% 的问题，但很多人还会揪着那 1% 不放。

就像

也难说服 DBA 去学习一个新东西

有的时候观点会受到经验影响。

恩，确实是

也和经验有关，确实很多人喜欢 sql。ORM 也一直受到到各种各样的质疑。

一个 Java 项目想要转起来，需要 n 个人。。。RoR 一个人就搞定了。。。

在滴滴也是 web 界面。但想看表结构，还是得连上某个环境的数据库去看。。。

界面这种，都是大家自己提交自己的，没办法知道数据库有哪些改变。RoR migration 可以都写到代码里，直观方便些。开发体验好一些。

不过既然都用 Java，还谈什么开发体验呢。。。

RoR 框架搭的比较好，感觉换 java spring 这种，早就没法维护了（连 schema、migration 都可以没有

java spring 框架弱，外加想怎么写就怎么写，所以才要微服务（故意黑 java 和 java spring

不过 300 个表，感觉也需要考虑切一切了。

目次有 300 个表 ，有点可怕。

报表主要是查询一般比较耗时，查询的时候又可能会有锁（mysql 默认隔离级是这种），锁了之后，就不能写了。也就是其他服务写的时候，会卡主那么一会。也许会卡主很多请求。

就是报表有查询，可能卡主其他服务。

看描述，这个需求点是两个，一个是增量，一个是聚合接口。

增量的话，性能可以有很大提升。

想要聚合接口，原因是什么？是性能上的考虑，还是编程容易程度上的考虑？

如果只是性能上考虑，还可以考虑下短连转长链。

如果是对前端友好，感觉网关比较合理。报表微服务，可以做这件事，但这个服务做报表的，没有理由管首页的事情。

业务和报表，这个在查询上有很大区别。一般业务不会查很多数据，有一致性、实时性要求。报表，一般有很大查询业务，但实时性，一致性，要求都不高。所以应该是两个单独的服务。

好奇问一下，报表服务，一般都很慢，直接连数据库，会不会拖垮整个服务？

应用多数是 IO 密集型的。就是大部分时间都花在读写、外部调用上。

同步框架靠线程在处理并发，线程切换耗费 CPU，线程本身也占资源。

异步框架，可以解决并发和性能问题。

但性能的瓶颈，更可能是出现问题的地方是存储。如何设计合理的存储结构才是问题的关键。

再然后是时间复杂度和空间复杂度。

现在的项目什么情况应该选择异步框架呢？

框架首先要能横向扩展，能横向扩展，靠堆机器，可以解决多数问题。绝大多数框架，都可以横向扩展。

之后是响应速度，速度确实重要。但多数应用对这个要求不高。多数问题，也没出在框架上。github 用 RoR 不是用的也很 happy 吗？

有的场景，确实有并发压力，比如 IM。多数的 IM 厂商都用 Erlang，但钉钉用 Java 玩的也很 high。而且，就是用了 Erlang，还是有很多问题要解决。

框架、语言和开发者的关系，就像赛车和车手的关系。想要跑的快，不仅仅要有好的赛车，还要有好的车手。

应用开发，会出现瓶颈的地方有很多，框架仅仅是其中一个。

最后，什么情况应该选择异步框架呢？

短连，同步问题不大。长连，一般用异步处理（连 RoR 的长接模块都是异步的）。

再就是，机器的钱，真的是需要考虑的因素了，对比人力成本以及运营成本而言。

再或者，本身对某个异步框架熟悉，或者处于技术好奇（别把喜好包装在各种理由之下，别总单拿性能说事，单说性能，不上量子计算，都有性能问题）。

感谢

我大体明白你们怎么定义 SLA 了。是不是任何一个服务 crash 了，就是不可用？个别 API 500，不认为不可用？

每日峰值调用能达到 5k qps....我们用 go 改造一些关键服务，顺利的降低了整体负载。

那就是，使用 go 之后，可以更省内存和 cpu 吗？

那篇文章，简单扫了下，总结下来就是 ruby 不火了。技术热点转移了，再就是本身的问题。

本身问题有 3 点：

1. 并发
2. 不合适大规模工程开
3. 不好招人

并发这个，目前主流还是机器换人力。

不合适大规模工程开发

你的回复，好像没有提工程的问题。比较好奇你们实践后得出的结论是什么？

“不合适大规模工程开发”这个本身是很模糊的概念。比如 java 被认为更容易大规模开发。但 java 的应用真的就 bug 少了吗？真的就更快了吗？似乎也不见得。

不好招人

中级的不好说，高级的感觉都不好招。还有一个问题，一个 ruby 开发可以解决的，用 go 可能要用 3 个。在这个假设下，那就是招 3 个 go 比招一个 ruby 容易。才能说 go 比 ruby 好招人。

可能整体来说，是更看好 go 的未来，所以想在 go 上多投入一些？

请教下 可用性 具体是怎么计算的？

还比较好奇为什么换到 go？收益是什么呢？

先理解了线程、阻塞 IO 再到非阻塞 IO，然后再回过头看细节会好些。

单个线程 指的是什么？server 的 scheduler 设置为 1 吗？

应该是 comet，不是 router，我看到“有状态”，理解错了，尴尬了。。。

我们的和 ActionCable 差不多，维护用户连接、router、讨论组和人的关系。

如果只是存储关系的话，redis 应该就够了。

恩，有个 timer，一段时间连不上，就胡重连。ActionCable 我记得也是有重连的。

IM 很多信息，都是走的长连接，长连断了，相当于 app 不可用了。

没。。。我们组是搞 IM 的，所以对这个比较了解。

恩，是的。ActionCable 更像个通知推送系统。做实时的东西就很吃力了。

都会重连，因为有重连、timeout 机制，有的时候会重连多次。

IM 最蛋疼的模块，就是那个 ~router~ 负责长链的模块

处理消息的服务有很多方法减压，广播消息不是多吗，那咱就上 cassandra。还可以把写扩散变成度扩散。消费不过来，丢消息队列慢慢来。

~router~ 负责长链的模块 却必须广播，创建一条消息广播 n 次。消息队列慢慢消费？不存在的，消费慢了 IM 还不成邮件了。

也有很多办法，比如限制讨论组大小，据我所知，网易内部 IM，最大群组是限制是 500，微信也限制了群的大小。不过还真不清楚钉钉大群是不是可以随便创建的。

但大群也还是要搞，就是麻烦，比如钉钉就把大群拆成了若干小群。然后还有限流、限频、服务降级打了一套组合拳。

恩，还要这玩应是有状态的！

API 服务是无状态的（有状态的丢给存储），水平扩展，重启大法，玩的六六的。

重启一台 router？恩，用户要重连的，搞不好还要重连几次的。。。

~router~连连服务 就不好这么搞。Phoenix 的 pub/sub 为了水平扩，就把一条消息发给所有服务，然后再有服务转发到对应的链接。

http 网络抖了，服务器一点感觉也没有。但 ws、tcp 不一样，网络一抖，马上跟着抖，简直是网络质量监控器。

还可以用 select 过滤出来需要的

array = [ 3, 4, 7, 12 ]
result = array.select do |elem|
  elem > 5
end

函数式编程的思想是，与其改变变量，不如生成一个新的。以为改变变量太复杂了。

遍历，生成新的这种，除了极特殊情况，不会成为瓶颈。

Redis 也有多线程版本 https://github.com/JohnSully/KeyDB，但不是官方的。

而且实现的似乎也比较粗糙：

KeyDB works by running the normal Redis event loop on multiple threads. Network IO, and query parsing are done concurrently. Each connection is assigned a thread on accept(). Access to the core hash table is guarded by spinlock.

感觉在 CPU 核数很多的时候，性能会不会随着核数的增多而线性增长。

Redis 可以做集群，来分表，一定程度上，也可以利用多核。

话说回来，现在一般服务器，8 core 也就到头了，能充分利用多核，也不见得是会带来多少实惠。但这件事本身很有趣。

最好也关注一下，timeout，有没有单独的线程池。

es 有的时候，会比较慢。搞不好，搜索会垮掉。这个时候，最好可以不影响其他服务。

这几个 gem 我没看过源代码，无法给出具体的，不好意思。

linode 最便宜的是一个月 5 美金，可以考虑下。

试了一下，报错 500，然后客服说你换个客户端试试。。。感觉不靠谱，还不如自己搭。

也不算是一致性。一致性说的是任何情况下，都是“对的”。

共识算法，只要最终达成一致就行。

就是对某件事情达成一致。比如 elasticsearch 有多个节点，这几个节点通过一系列的交流，都认为，某个节点是 master 节点。

比较好奇 Shopify 现在的技术架构还有需要解决的问题