哈哈，是的，这部分没说明。

这个想为后面讲 cow 或者 mmap 服务，就忽略了

page size 没仔细研看过，我知道的是为了可以给一个 process 更多地内存？不是很确定。求指教。

之前的团队后端十几个人，语言用到了 clojure/java/erlang/rust/kotlin/ruby，除了开发还有各种分工，比如负责网络，负责存储，负责稳定性，并且还依赖不少内部团队的服务。

500 人的团队，可能本身就不需要那么多的纯开发。

new 一个对象？

这个 https://zhuanlan.zhihu.com/p/251366985，不过已经结束了 总结 https://zhuanlan.zhihu.com/p/347108301 他还组织了读论文活动 https://zhuanlan.zhihu.com/p/382412836，也已经结束了。

知乎上他们有人组过一个团，他们似乎刷完了操作系统，现在在刷分布式。

他们做的还挺好的，整理了 wiki 之类的。

Martin 才是我们的榜样，人帅技术好，还会做菜！

没有没有

不是不是

哈哈，不是大佬。

最主要还是看你兴趣了。工程方面，6.824 分布式系统挺有意思的，相对来说对基础没那么高。

他们网络，数据库方面的课程也有，资料放出来的可能没那么全。

他们还有线性代数，据说不错。

数据库 CMU 15-445 和 15-721 资料比较全。

网上有不少大学的公开课，一般可以挑选比较有名的，或者资料特别全的，最主要是 lab/project 要有。

嗯，是的。加油。

这个其实可以引出来很多东西。

一个是超过这个最大吞吐，系统的行为是什么，怎么解决。

工业的解决方案是加限流。这个是试用简单的场景。再好一点是用背压。网飞有一个 lib，机制类似 tcp 拥塞控制。facebook 的 memchahe 也用了类似的机制。

这个 https://pdos.csail.mit.edu/6.S081/2020/readings/mogul96usenix.pdf 讲了一个类似的事情，主要是解决方案。

Congestion Avoidance and Control 这个里面讲了背后原因，

开进程

经历过和听过的微服务改造，原因大体是可用性（最多），可维护，可扩展。

数据库性能那么好，分表前可以抗非常久。

分布式事务的话，如果服务拆的合理，或者一致性不那么重要，可以没有。

http 性能完全可以接受，主要是没有 schema。

rails 没有什么适合不适合的，没人搞罢了，就拿 github 来说，一个企业服务，三天两头挂，也没见他搞啥…

公司有位清华本硕的高职级的人，写技术文章，画图不给坐标，没有任何引用。人家可能是真大佬吧。

三个党员，就应该成立党支部。 http://wenda.12371.cn/liebiao.php?mod=viewthread&tid=577492

好像有三个党员，就要成立党支部

我得强调一下，这个帖子是正经招聘贴！

我就是过来舔大佬的。

弱弱的问一下，如果不找工作，可以加大佬的微信吗？

web 开发一个是降低复杂度的，这一点 rails 开起来似乎做的不错。 还有可扩展和高可用。这两点，rails 社区关注的似乎不多。

web 开发，难搞的地方在存储。再有些其他的，比如网络什么的。

语言的话题，有的时候，就会变成豆腐脑是咸的，还是甜的。

不谈复杂度的重构都是耍流氓。

好奇这种情况下，pg 也没办法提供其他查询和写入了吧？

过长和特殊符号本来就不是正常用户会输入的，完全可以干掉。

对于后端来讲，不限制输入长度的话，可以算作 flaw 了。

后端没义务让所有场景都能返回，但有义务保服务对绝大多数人是可用的。

限制 term 长度？或者过滤掉特殊字符？

MySQL 有类似的，压测的时候用过，不过误差有点大，也没仔细找原因。

mysql> SELECT count(*) AS TOTALNUMBEROFTABLES
   -> FROM INFORMATION_SCHEMA.TABLES
   -> WHERE TABLE_SCHEMA = 'business';

Oracle 有个 Zone Map 的优化，会单独记录 count 之类的。

ssh -R，把服务器端口代理到本地。