确实不太好，我删掉了。

应该是 Java 写的

Ruby 能玩的东西没有其他语言那么多。

微服务，稳定性，可扩展（scable），存储，并发这些社区似乎都不是很关注。

见过别人做架构，做扩展性/做可用性，确实厉害。但 DHH 的态度是，花这力气，还不如多买几台机器。

稳定性这块，GitHub 一个 Web 服务，动不动就挂。。。GitHub 是一个企业服务，大家强依赖，挂是很丢人的。。。

GitHub 比那些有体量了，就换语言花钱雇人重写的还是强了不少的。

技术呢，用不用得着是一方面，但有没有趣，又是另一方面。

打个不恰当的比方，比如拥塞控制这件事，不考虑性能，不考虑稳定性，那随便写写，又简单又好维护，多好。但不考虑这些，又怎么弄清楚这个事儿呢？

如果性能不重要，稳定性不重要，扩展性不重要，算法不重要，就快速露撸功能最重要，好玩的就不多了。

唠叨了这么多，最后还是希望 ruby 可以探索更多的领域和更多的问题。

ruby 在可读性，高效开发上，做了非常多的探索，非常值得尊敬。但还是希望 ruby 可以做更多的事情。

国内某云厂商的运维升级 redis，不做备份。。。他们升级脚本有问题，rollback 脚本还有问题。。。

即使是这样，要是我的话，还是会打一下马

（楼主是不是可以给这个人的信息打一下马赛克？

高产

惺惺相惜？

哪都有能人，哪都有混子。在大场 ppt 是必备技能，但我觉得写 ppt 挺重要的，但全靠 ppt 就不好了。

大厂能人多，水货也多。这个可能是基数问题。

小公司，相对简单些，工作搞好就行。大厂要会表现。

技术上，小半看工作内容，大半看自学。但大厂基数大，更容易遇到能人（可能是技术好，可能是混的好）。大厂相对来讲（有些事情没到一定体量是不需要的，比如微服务），工作场景一般会更有意思些。

一个共同点是，不少人的阅读量不大，多数以自己的理解或经验作为依据。

有 es bulk inser，写个脚本就可以搞。

每秒 2000，一个多小时就能写完一千万的数据。

数据库也还好，都是连续性的读。

要想稳妥点，开始可以慢点。

六六六

这个也是很重要的一点。

嗯，有的数据库是用了 OS 的 buffer，比如 PostgreSQL。

用了 OS 的 buffer 会有一个叫 double buffer 的问题，Architecture of Database System 里面有提到这个问题。

CMU 15-445 里面也是建议是 buffer 由数据库自己维护。

你这么一说，这个地方叫元数据好像也不太合适，我改一下。

恩 ，我写错了，感谢。

那个老师的讲法，我按照我的理解整理了一下。

微服务的话，一个一个升级，风险会小很多。 还可以部署两个版本什么的。

但升级几个服务也是挺麻烦的事。

唠叨一下。

设计数据密集型应用的作者，把开发开发分为这样几个方面

可维护性，可扩展性，可用性。

可扩展性，也分为横向和纵向。纵向是单机的性能能到多少。那么，语言性能影响的是纵向的扩展性。

设计应用，如果能横向扩展，几乎可以说是赢了。而横向扩展跟语言性能没什么关系。

再来看下我们的环境，首先是硬件越来越便宜，cpu 单核性能已经不那么容易增加了，得靠多核提升性能。

性能瓶颈多数是在存储这。我们拿 Facebook 的 memcache 集群为例，有篇论文是介绍他们怎么玩的。他们的优化都在处理横向扩展，如何应对突发流量，如何减少网络请求之类的。单机的优化很少。分布式里，似乎都不是很在意单机的能力。

再比如 discord 用 rust 替换了一个 erlang 的 orderedsort 实现，性能翻了多少多少。先不说没找到具体的测试用例、机器情况。他们的实现，erlang 的是遍历，rust 的是跳表。当数据量比较大的时候，算法的重要性远大于语言。顺便一提，erlang 有 ets，sort 是平衡树，c 实现，并发性非常好。

有的时候，看清楚问题是什么，当前的情况是什么，更重要。

问题到底是快速迭代还是极致性能（高性能，多数的时候大家还是用 c++，相对来说 java 差不少，外加加上 gc）。如何利用现有资源，比如分布式，大内存，算法。

语言不过是工具盒里的工具，性能不过是这些工具的一个属性。

服务不可用，有多种情况。

一种是临时性的，比如重启，这种只要加一下超时重试，就可以解决。

另一种是服务直接被打趴下了。这个时候，需要调用方放慢一点速度，比如限流、熔断。

还有用类似 tcp 的拥塞控制来做的，比如 网飞有个 java 库是 https://github.com/Netflix/concurrency-limits。

Facebook 的 memorycache 集群也有类似的机制，说是可以降低延迟 https://pdos.csail.mit.edu/6.824/papers/memcache-fb.pdf 3.1

限流需要预先知道服务能承受多大压力，如果服务比较少，依赖简单，还行。但复杂了，就没办法知道这个数值了，就需要靠拥塞控制的思路搞。

应该是浏览器用 http2 的话，必须要用 TLS

https://stackoverflow.com/a/54458547/2477886

用 TLS 的话，需要签发证书。

Rust 和 Ruby 应该是所有编程语言里面最类似的了

你这么一说，Ruby 一定和 R 有关系，R 一定和 System R 有关系，根据关系的传递性，Ruby 和 System R 也有关系。

我也是最近才知道

bpf 这个东西我就是知道个名字，不过直觉上和 tracing（dapper 就是做 tracing 的）是一类东西。

有人这么形容 bpf

以前的一些 linux 指标，像是蜡烛照亮了内核，bpf 像是给内核打开了个灯

系统复杂起来了，都不好理解。

Google 他们为了理解他们自己的系统，搞了一个叫 Dapper 的东西，用来理解分布式系统。

最近还有一是 BPF http://www.brendangregg.com/bpf-performance-tools-book.html，好像也可以当 understanding tool 用。

搞 Rust 的好像有不少人弄 BPF，Erlang 好像也搞过一点，不过后来似乎是废弃了。

不知道 RoR 有没有类似的。

（要有兴趣，有时间我们可以讨论呀（虽然这两个东西我也不咋懂

我有 acm 的邮箱，不过花钱就能买。

俗称大忽悠

确实讲了不少如何思考的东西，还真挺有用的。

我们组里做技术分享，大家都认认真真做 ppt，但我们技术负责人分享就只用 emacs。但他却是把问题讲的最清楚、最明白的。

Robert Morris 讲课也不做 ppt，课件就是有缩进的文本。同样的是东西讲的太明白了。

但他们这种我都学不来，我对技术理解没那么深，也讲不了那么明白，只有努力并老老实实做 ppt。

我们技术负责人几乎不怎么管我们。和产品、前端、测试团队比起来，我们后端是最松散的。

但他在技术上影响了我们很多（我们很多慢慢的都按照他的套路玩了）。比如忽悠我们买 Safari Books，忽悠我们看有价值的技术书籍、做有价值的思考。再比如看他怎么写代码、做架构、解决问题。他搞事情，简直就是降维打击。

没逼我们干过什么，但真的是被他忽悠忽悠着就上道了。

做一件事总有一些规则，比如演讲要写 ppt，管理要打卡。但有的人，可以打破这些。

恩，是的，无状态是说服务本身没有状态。

如果是无状态的服务，比如 API 服务，一致性一般是由后面存储保证。

一般 API 服务，可以不去考虑 CAP。存储服务（包括有状态的服务），比如 ETCD，才需要考虑 network partition 的时候，是否可读可写之类的。

一致性一般是由后面存储保证

不过也有特殊情况，GFS 存储就不保证一致性，由 lib 来处理。riak_pg（pub/sub），network partition 的时候可用，连回来的时候解决冲突。

ETCD 的一致性保证有点迷，读的时候是有可能读到旧数据的。

ttps://etcd.io/docs/v3.3.12/learning/api_guarantees/

然后，network partition 的时候，有说能读，有说不能读的，https://stackoverflow.com/a/28927474/2477886。

ETCD 基于 Raft，但没完全用 Raft，Raft 的 request 都是要经过 master，这样的话，没办法横向扩展，ETCD 应该是没有完全用。。。具体怎么用的，还得看代码。。

debug 才是麻烦的事情

一致性，有些时候也没那么重要，可以牺牲掉换新能，或者业务层处理一下。

很关键的地方，再根据具体情况处理。

CAP 是存储要考虑的，除非这个服务没办法搞成无状态的才需要考虑。而且几个节点 partion 的可能很小，可以不考虑。

赞赞赞👍

听起来蛮不错的，不过我还没试过看小说，觉得词汇量比较大，会不太容易

语法可以靠猜，大体理解应该还 ok。