• 应用多数是 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 多路复用 at 2020年03月24日

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

  • 如何无成本办一场大会? at 2020年03月21日

    群 * + 野战?

  • 350 行实现一个简单酸酸 at 2020年03月17日

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

  • 直播 -- 弹幕系统简介 at 2020年03月09日

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

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

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

  • 直播 -- 弹幕系统简介 at 2020年03月09日

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

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

  • 直播 -- 弹幕系统简介 at 2020年03月09日

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

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

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

  • 直播 -- 弹幕系统简介 at 2020年03月09日

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

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

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

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

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

    恩,还要这玩应是有状态的!

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

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

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

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

  • 搞了个 awesome-otp-learning at 2020年02月24日

    😀 😏

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

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

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

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

  • 搞了个 awesome-otp-learning at 2020年02月22日

    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 我没看过源代码,无法给出具体的,不好意思。

  • 大家怎么连接谷歌的? at 2020年02月04日

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

  • 大家怎么连接谷歌的? at 2020年02月04日

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

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

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

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

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

  • 相当于执行 select * from some_table,考虑到行数,这个本身就很慢。也许是这个还没返回。

    如果 crash 的话,应该是内存爆掉了。

    不过石锤还是要试试看。

    解决方案其他人已经说了。

  • 那种可以按秒付费的,用的时候就开,不用的时候就删。

  • redis 单线程,mac 4 core 足够玩集群了。benchmark 在云上搞就可以。

  • 启动的时候,把所有表读出来,然后动态创建 model 呢?

  • 应用大体分为两种,IO 密集型 和 CPU 密集型。多数 APP 都是 IO 密集型。

    好的架构,要把应用层的压力,尽可能的转移到 IO 上。

    高端的玩家甚至会根据应用场景设计存储,比如 Cassandra。

  • 就是 http 请求而已。。。一般不这么做,罢了。看你是什么需求。