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

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

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

不过石锤还是要试试看。

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

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

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

启动的时候，把所有表读出来，然后动态创建 model 呢？

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

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

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

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

能

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

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

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

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

1 无脑堆机器 不行

行

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

没事

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

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

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

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

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

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

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