@nsynet #3
<黑客与画家>我只试读了前面一部分，觉得他的观点很有启发性。

作者开篇理性的分析了不同性格的人的处事方案与相应的结果，作为一个从小比较内向的现役研发，我觉得很多点都是符合的，也对年轻的自己释然了，不再纠结。

有时候多分析、了解自身，或者同类，能避免迷茫，更快找到属于自己的道路。

@Antidictator
做了什么事被降权？

今年考研吗，这两年竞争很激烈了，加油吧。

想看的斯通纳和黑客与画家都没有优惠🙃

看来你还不是很清楚这是一家什么样的公司：

UCloud 面试官 diss 应聘者 /t/545393
UCloud 拖欠社区活动推广费 /t/377051
...

一家管理混乱、信用缺失的公司。

做云的公司多了去，哪来这么多独角兽。

---

Q:以前一直用 c++ 做游戏, 现在想转互联网后端, 做 Go 或 Java, 但是投了简历一直也没消息, 互联网的那些技术栈也比较难实践, 有啥好的方法么...
A:先用 go 或者 java 做点实际的东西出来，比如我之前团队有个小伙之前也是用 C++，投我这边 Go 的职位。他业余时间用 Go 做了个 V2EX 的客户端，当场就要了。

---

Q:如果想重试大数据开发的话，平时应该多关注哪些技术栈呢，从服务端开发转过去有哪些地方需要了解提升的
A:大数据开发这个职位挺缥缈的……我不清楚你说的大数据开发是指的数据分析、数据中间件、有大数据场景的后端应用还是什么别的。

第一个，一般就是流式处理框架，Hadoop 全家桶之类的数据处理框架。
第二三个，跟普通后端开发没啥本质区别。

---

Q:.用户的关注列表分页拉取时，如何把正在直播的主播前置到列表
A:假设正在直播的主播不多，可以单独存正在直播的主播，插到关注列表前面。

---

Q:主播的粉丝量很大时，开播如何及时推送给粉丝
A:1 想办法并行取粉丝关系，并行推送 2 优先推送核心用户 3 改成拉取模式，实时获取当前主播的直播状态

---
end→#128

---

Q:很多公司要求的大数据高并发经验，在小公司工作的机会永远用不到的如果才能通过这种 offer
A:分两方面说，很多地方招聘（包括我这边）虽然更倾向于有高并发经验的人，但是这也不是个绝对的必选项。我的判断条件是“是否达到了所在平台的天花板”和“是否有持续进步的潜力”，大部分情况下，能把当前工作搞的很好的人，也能把高并发搞的很好。

另一方面，我一直认为能去大厂还是尽可能的去大厂，毕竟大厂能带来的经验和提升很多小公司确实没有。通过自学能储备一些知识，网上的教程也有不少，不过经验的差距很难解决。

简单来说，把自己想象成应届生，工作几年没有高并发经验和应届生没有工作经验面临的状况是类似的。

---

Q:一个合格的 5 年后端要具备哪些能力？
A:这问题有些宽泛，一线互联网公司的五年跟不知名公司的五年，完全不是一个概念。

我只说一线互联网公司的五年，基本上应该是小组长，能够独立设计日活百万级别的后端系统架构，在开发规范和效率方面能够指导初级工程师和工作。此外还有复杂问题的分析和解决能力。

---

Q:请问 估算一个对象的大小，这问题意义在哪？
A:没看懂你的问题，是说 jvm 里的大小还是序列化后的大小？前者一般是面试的时候考查对 vm 的理解，后者是缓存容量评估。

---

Q:你们团队有测试开发吗？如果有，请问他们都做些什么工作？他们的技术栈大概是怎么样的？
A:测试是另一个团队，他们做的事情是写测试框架、搭测试系统、写测试用例。
技术栈跟普通开发差不多。

---

Q:有使用 K8S 应用的案例吗，比如说用在数据库扩容上面
A:我的团队应用 k8s 更多的是在线下或者半离线业务场景下，做后台系统或者一些非实时任务。用来降低整体计算成本。至于线上业务，k8s 的能力还不足以让微博这种体量的公司开箱即用，这个改造成本也会比较高。

---

Q:老板好，正文描述的几个系统主要是用什么技术栈构建的呢？能谈谈当时技术选型的取舍吗？
A:语言 Java 用的多，好招人；框架分场景，比如做消息推送服务就用了 netty。取舍：尽量好招人的技术栈。

---

Q:处理高并发有哪些难点？以前感觉这块挺神秘的，接触不到
A:能用缓存就用缓存
考虑并发场景下的一致性
在框架里做好断路器和保护机制
做压测和容量预估
加机器-.-

要做高并发，还是要有场景。这玩意就是个难者不会，会者不难的东西……

---

Q:大佬你现在自身的技术栈是怎么样的。3 年后端参考下。
A:我是属于那种“什么都会一点”的技术专家，如果单独说技术栈的话就太多了，列不下来。

换个回答方向，说一下我认为自己的技术强项吧。

一个是系统设计能力，能够设计微博这种用户和流量规模的后端服务。
一个是对操作系统、网络和 VM 的理解，能够排查复杂性能问题。
一个是业务方面的能力，包括通讯直播视频和社交媒体相关业务和对应技术（消息推送、视频编码、文件存储，等等）

总结下来的话，就是基础知识+架构经验+领域知识吧。

---

Q:微博有 golang 这块应用吗？
A:微博的部门很多，每个部门情况不一样。在我这边有一部分 golang 的线上应用，也有一部分管理系统用的是 golang。

高质量帖，一条条看完了，边看边整理了下觉得有用的 QA，供不喜欢爬楼的参考，感谢秦老师。
－－－
Q:怎么做到增加机器能线性增加性能的？
A:线性扩容有两种情况，一种是“无状态”服务，比如常见的 web 后端；另一种是“有状态服务”，比如 mysql 这种数据库。

对于无状态服务，一般只要解决了“服务发现”功能，在服务启动之后能够把请求量引到新服务上，就可以做到线性扩容。常见的服务发现包括 DNS 调度（通过域名解析到不同机器）、负载均衡调度（通过反向代理服务转发到不同机器）或者动态服务发现（比如 dubbo ），等等。

对于有状态服务，除了要解决服务发现问题之外，还要解决状态（数据）迁移问题，迁移又分两步：先是数据拆分，常见的都是用哈希或者一致性哈希把数据打散。然后是迁移，常见的办法有快照和日志两类迁移方式。也有一些数据库直接实现了开发无感知的状态迁移功能，比如 hbase。

---

Q:代码优化，从哪些方向入手
A:代码优化分为几个层次。

初期的优化主要集中在功能上，不写 bug。
然后是鲁棒性，在异常情况下不写 bug。
然后是性能，提高系统吞吐量，或者执行降低延迟。
然后是可维护性，在团队开发过程中降低其他人的理解难度，再做好一些，通过设计做到模块解耦，降低删除无用代码的难度。
然后是可扩展性，能够预测系统或者业务的发展方向，提前设计好锚点，让系统能够通过扩展而不是修改的方式增加功能。

再往后就是各自的境界了，我至今也还没参透……

---

Q:做「你关注的某某人评论了某某人」之类的和几度人际关系相关的复杂功能的时候有没有遇到哪些性能上可能的问题
A:这肯定是有性能挑战的，比如“你关注的人也在关注”、“你关注的人最近发的微博”等等，都可以理解是二度关系。主要挑战点是数据的扇出量会比较大，我关注了 1000 人，这 1000 人又每人关注了 1000 人，那就是要 100 万的数据做处理。解决办法要么是减少扇出（比如限制关注人数量），要么是离线算数据，在线取结果。

---

Q:视频存储和提供有什么难点嘛，常年 mysql 中 varchar 选手想了解下
A:视频存储和播放难点要分开说。

对于分布式文件系统来说，有几个难点。
一个是文件大带来的执行效率，比如用户上传一个 10G 的文件，要 1 秒之后立刻能够访问，需要做一些性能优化的策略
一个是可用性，在某台机器宕机之后不能影响用户数据，需要有数据迁移和冗余的策略。
一个是文件多带来的元信息膨胀，分布式文件系统都要保存每个 key 的元信息（比如存在哪台机器上），当文件超过几百亿之后也会带来元信息存取的压力。

而播放一方面是整体缓存架构和调度策略的选择，另一方面的难点主要是对于网络（在目前场景下，主要是 tcp 协议）的理解、对协议（比如 http/http over quic ）的理解和策略的选择。

当然，在国内 isp 环境下，更多的还是与人斗，其乐无穷。

---

Q:分布式事务这块是怎么处理的呢？是由业务系统去做一致，幂等之类的保证吗？还是有统一的中间件或框架呢？
A:微博这边的一致性要求并不高，一般是通过幂等性和常规的乐观、悲观锁实现的，分布式事务（至少在我这里）用的不多。

---

Q:在系统或功能模块设计阶段是如何考虑系统的扩展性的呢？是快速原型，实现，上线，后续迭代升级，还是说会在一开始就做一些复杂的设计？在这方面是怎么作取舍呢？
A:设计阶段要考虑的首先是“系统哪些功能是必不可少并且需要快速验证的”，然后是“系统 2 年以内有可能会有什么变化”，觉着不好设计的原因还是设计少了，踩的坑不够多。经验多了，就没这类问题了。

---

Q:视频类的后端开发和其他图文为主的社区产品后端开发，架构、技术选型上有哪些不一样的地方
A:从整体的角度来抽象看，要做的东西其实差不多，都会有增删改查，然后内容理解+推荐；视频特殊一些的地方是有视频编解码。
具体技术选型来说的话，业务上的增删改查都差不多，但是视频存储都是对象存储服务而非关系型数据库；视频方向的内容理解更多的偏向深度学习的实现；视频编解码是一门独立的专业，不过由于太耗计算资源所以还要配合着调度系统一起实现。

---

Q:怎么做才能做到不同地区，用户播放视频都比较流畅？会用到类似 CDN 的部署架构？
A:如果往深了说，流畅是几方面的综合结果，包括视频体积、CDN 部署、播放调度、防劫持、播放调度、防劫持等等。

对于你说的不同地区来说，最重要的方面有两个：一个是 CDN 部署和调度情况，尽量让用户访问边缘节点；然后是防止劫持，一般流量被劫持后都不可避免的性能变差……

---

Q:应用服务器的数据库连接池应该设多大？看了一篇译文 jianshu.com/p/a8f653fc0c54 的观点是"连接数 = ((核心数 * 2) + 有效磁盘数)", 不知道实际一般是不是这样计算
A:我没太看懂你的问题，到底是数据库服务的连接池，还是应用服务连接数据库的连接池？文章里我简单扫了一眼，似乎是后者

不过无论哪个连接池，核心问题还是“同一时间内，需要同时请求的数量”，这个其实就是个数学公式，类似“这条路上每天要跑 1000 辆车，每辆车跑个来回要 10 分钟，那么路建多宽合适”。按我的经验，连接数多设一点不会有太多问题（除非设的数量太夸张把系统连接数耗尽了），而设少了，在系统负载变高的时候就会出现非常明显的排队现象，这对服务性能的影响更大一些。

@SilencerL #6
@tongyang #17
@littleylv #20

公司、办公室室内开空调的很多，
前两天回暖，人多又有电脑，工位上会比较闷热。

出门穿外套，看椅子后面有外套。

开的 Land Rover，每月一修;)

我来查查是不是真的优惠

@zhttty #4
居然会在这里看到这个 ID。。。身败名裂，张恒。

---

一个人去比较贵的餐馆，就已经有点受不了了，更别说火锅🙈

尽量说找当地的朋友看能不能聚个餐吧。

或者习惯了也好。

让他不用管项目，每天去给甲方捶背、按摩，这样对方的感受最直观、真切。

办公室的 i5-8700 都能跑一百多
imgur.com/zXNbp2z

临时参团的吗？要不要继续分享下带了什么装备。

很不错的经历，厉害。