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

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

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

    不过石锤还是要试试看。

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

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

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

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

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

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

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

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

  • ShowMeBug 核心技术内幕 at 2019年10月30日

    @WalkPhoneGo 功能、性能、可靠性,这些是不同的东西?为啥跟你讨论可靠性,你为什么非要说功能和性能呢?

    至于为什么,不好意思我没研究过。

    其实挺期待你说说原因的。

    那按照你的逻辑,我试着回复一下哈。

    1 无脑堆机器 不行

    大量用户 是多少 稍微多一点人 AC 就是一具尸体了

    没事

    这个不是框架能保证的 需要自己实现

    1、2、4、6 都是功能,需要自己实现。

  • ShowMeBug 核心技术内幕 at 2019年10月30日

    如果这么理解可靠性,也不是不可以。

    关于这个模块,我说下我理解的可靠性吧。

    坦白的讲,我不是很介意性能差一点,但 AC 似乎是很不怎么好。更在乎这个模块可不可以横向扩展。能横向能扩展,就可以无脑堆机器。

    再就是,在一些奇奇怪怪的场景下,这个服务还可以健康的活着。比如大量用户重连的情况下、流量激增、一台机器突然挂掉,剩下的节点是不是能正常工作。

    以及,用户断连到重连,这段时间内的消息,要怎么处理(有单独服务处理会更好)。能不能确认消息已经传到客户端有单独服务处理会更好)。再复杂一点,有序。