那是因为那个 HR 的后端 hc 差别不多够了，但前端 hc 还没够，拿你完成 kpi 所以这么和你聊而已。不用理会的。

“没有分布式经验就不能参加分布式系统开发”，也是伪命题。即使没有相关经验，你可以先学习分布式系统相关知识，向面试官证明你知识储备和学习能力都足以胜任，其实就可以了。

分布式系统无非是性能，一致性，容错，冗余等话题。已经是几十年的话题，太多资料可以学。

关于做前端和后端，还有换 tech stack。前端还是后端，我也经历过从 ruby on rails 换到 java，其实不用太关注“用什么语言写代码”这个事，这在日常工作中是个特别微不足道的点。

一般一个团队只要一个有经验的人来处理一下架构问题，其他人搬砖 crud 即可。各个人都要求无短板的话，团队成本会过高。而且团队里对于架构都会有自己的看法，到时候要统一思想也是问题。

没岗位，比较难坚持，还是挺难撑下去的。

我之前在阿里，Ruby 写了 3 年，能用的项目少，各方面原因都有，后面不得不写一些其他的，比如 Java、Node.js

然后看你说的，难道你作为 Rails 工程师，不会前端么？

大厂后端对算法要求很高。很多地方都需要极致优化。

1. 首先，是人家怎么看的问题 大家可能对后端的理解不一样，或者 hr 不是很理解 RoR 的工作方式。可能工作内容 ok，但别人没理解。面试什么，主要还是面试官说的算。。。

2. 然后分布式个人经验来说，这个还是有用的。 我们被分布式数据库坑了两次，最后是了解了实现，才解掉。 不久前才刚跟同事扯时间戳没有办法保证时序（起因是我需要调用他的服务，我的业务需要有时序保证，他建议用时间戳，我跟他解释说时间戳帮助不大）。

   分布式会影响思考和解决问题的方式。想说的是有影响，但有没有意义，是不是好的影响，这就要看情况了。

   我们招聘对分布式没硬性要求，问到的情况也不多。

我三年前做过 1 年前端，现在这个职位 (一个 10 个 rubyist 的团队) 几乎是纯 Ruby, 前端要求不高，也就刚开始过来的时候改了一下前端，所以我个人认为自己做的是后端工作， 我会好好学和点满 js / typescript 外加 react 技能树的，leetcode 也刷了 2 百题以上了，以后要两个语言一起刷。 现在想好了，不受 HR 的分布式单词迷惑了，也对自己在就业市场有个定位了解。

“不久前才刚跟同事扯时间戳没有办法保证时序”

可否解释下？

恩，是这样的。改数据的时候，数据库，要知道两次操作的先后顺序。

比如 put(a, 1) 和 put(a, 1) 这两个操作发生的先后顺序。

如果这两个请求先后发送到两个服务器上个，server0，server1。

如果 server1 的时间比 server0 慢的话，用时间戳的话，顺序可能就反了，数据就是错的。

服务器之间需要 ntp 之类的协议同步时间，这个是不准的，有可能会差 100ms（只是打比方）之类的，还不考虑时间配错了之类的。

具体的可以看，设计数据密集型应用 里有关于时间戳的说明。

简单来说，就是分布式场景下，使用时间戳，作为顺序是不可靠的。

不要怂，互联网大厂也没多少高深技术，水平和流程也挺差的

如果你有做自由职业/独立开发/创业的规划，那么 Rails 最好还是不要丢掉

非常认同炮哥这句话。

分布式为了保证时序的策略通常有：

1. Lamport 逻辑时钟，或它的各种衍生逻辑时钟。CockroachDB 用的这种策略。
2. 原子钟提供的绝对时间。google spanner 用了原子钟的绝对时间策略。TrueTime
3. 有个中心节点负责顺序，用单调递增函数来保证顺序。所有其他节点做任何事情之前，要先和它沟通，要一个 sequence number。TiDB 好像用的是这种策略。

恩，是的

其实这个场景，比较合适的是 compare and set，设置之前，先查，之后掉 comap and set，失败了就重试，好处就是实现简单。

或者那个服务把查询请求代理到我这。

rails 工程师想去大厂还是得多网络社交。。。

所以真去做前端了？

Github 一直是用 ruby 做后端。哪里来的虚假消息说用 go 做后端，没有证据不要乱说好吗。

没要我。水平不行。