突然闲下来没事干，开个贴回答互联网后端技术问题

如何防止掉发？以及掉了的头发怎么长回来？

怎么做到增加机器能线性增加性能的？

@yesicoo 医院就诊皮肤科，一般脂溢性脱发都会外用米诺地尔，内服非那雄胺。

但更重要的是尽快接受“该掉还是会掉的”这个现实，保持心态乐观就好。

代码优化，从哪些方向入手

做「你关注的某某人评论了某某人」之类的和几度人际关系相关的复杂功能的时候有没有遇到哪些性能上可能的问题

视频存储和提供有什么难点嘛，常年 mysql 中 varchar 选手想了解下

分布式事务这块是怎么处理的呢？是由业务系统去做一致，幂等之类的保证吗？还是有统一的中间件或框架呢？

视频类的后端开发和其他图文为主的社区产品后端开发，架构、技术选型上有哪些不一样的地方

楼主有参与用 serverless 搭建后台系统吗？或建立部分 serverless 服务

@takemeh 线性扩容有两种情况，一种是“无状态”服务，比如常见的 web 后端；另一种是“有状态服务”，比如 mysql 这种数据库。

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

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

微博酷燃视频 PC 网页端可以增加一个搜索框吗，比如我想搜索“水煮肉片”。有搜索框会方便很多，不然每次都只能到百度里打一大堆

@axb 多谢， 长见识了

@EminemW 代码优化分为几个层次。

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

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

可以透露一下新浪短链接的一些思路么

@kindjeff 这肯定是有性能挑战的，比如“你关注的人也在关注”、“你关注的人最近发的微博”等等，都可以理解是二度关系。主要挑战点是数据的扇出量会比较大，我关注了 1000 人，这 1000 人又每人关注了 1000 人，那就是要 100 万的数据做处理。解决办法要么是减少扇出（比如限制关注人数量），要么是离线算数据，在线取结果。

PHP 程序员做 websocket 应用是学习 swoole 还是直接换门语言？

后悔成为软件工程师吗

怎么做才能做到不同地区，用户播放视频都比较流畅？会用到类似 CDN 的部署架构？

应用服务器的数据库连接池应该设多大？看了一篇译文 https://www.jianshu.com/p/a8f653fc0c54 的观点是"连接数 = ((核心数 * 2) + 有效磁盘数)", 不知道实际一般是不是这样计算

@zixianlaiye 视频存储和播放难点要分开说。

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

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

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

@lovelife1994 微博这边的一致性要求并不高，一般是通过幂等性和常规的乐观、悲观锁实现的，分布式事务（至少在我这里）用的不多。

无任何经济基础的普通程序员，哪座城市适合长期发展

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

@ssdde 这个我只能跟产品经理提建议了。

axb 老师你好，我想请问下微博的搜索架构是什么样子的？

@okoook 我这里没有作为使用方实践过，反而我们团队做的是更像是实现 serverless 的基础设施。不过据我了解微博内有一些团队已经有过实践了，具体效果我也不太清楚……

@ebony0319 就是个 key-value 的映射关系，感觉网上这类服务实现思路和开源代码一搜一大把啊……

@richangfan 抱歉，我对 php 了解不多，你可能在什么地方看到微博全都在用 php，不过实际上不是这样的……

秦老板，我就想知道为啥国内这么多 java，这么少 C#，而国外几乎是 1：1 的？

@axb，好的麻烦大佬，感谢大佬了，等了很久一直都没有搜索框，今天运气好恰碰到大佬亲自现身，实在有幸！

@patx 如果往深了说，流畅是几方面的综合结果，包括视频体积、CDN 部署、播放调度、防劫持、播放调度、防劫持等等。

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

@greatdancing 为什么后悔……？

@axb 谢谢解答，另外还想问一下在系统或功能模块设计阶段是如何考虑系统的扩展性的呢？是快速原型，实现，上线，后续迭代升级，还是说会在一开始就做一些复杂的设计？在这方面是怎么作取舍呢？

一个人有几千万个关注，这种数据结构怎么存呢。？

在公司业务没有多大并发量的情况下，要自己模拟学习高并发有什么好的建议吗

@coderqbc 我没太看懂你的问题，到底是数据库服务的连接池，还是应用服务连接数据库的连接池？文章里我简单扫了一眼，似乎是后者

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

@snxq1995 这个我不清楚，我只在北京工作过……

有使用 K8S 应用的案例吗，比如说用在数据库扩容上面

@misaka19000 抱歉，我对微博搜索的架构也一无所知……

应届生如何向中间件方向发展，大佬能否给些建议呢？十分感谢~

@Rwing 秦老板，我就想知道为啥国内这么多 java，这么少 C#，而国外几乎是 1：1 的？

不清楚，我 Java 关注的更多一些，Java+Linux 环境没什么硬伤，我觉着也挺好啊？

@lovelife1994 谢谢解答，另外还想问一下在系统或功能模块设计阶段是如何考虑系统的扩展性的呢？是快速原型，实现，上线，后续迭代升级，还是说会在一开始就做一些复杂的设计？在这方面是怎么作取舍呢？

设计阶段要考虑的首先是“系统哪些功能是必不可少并且需要快速验证的”，然后是“系统 2 年以内有可能会有什么变化”，觉着不好设计的原因还是设计少了，踩的坑不够多。经验多了，就没这类问题了。

@ebony0319 一个人有几千万个关注，这种数据结构怎么存呢。？

存不是问题，你用个普通 mysql，只要哈希的狗斗，都能存的了。难的问题是“怎么取”，这个要看业务场景。

@axb 是的，指应用服务连接数据库时设置的连接池大小，您的分析有道理，感谢。

@ebony0319 哈希的够多，抱歉打错字了

@axb 老板好，正文描述的几个系统主要是用什么技术栈构建的呢？能谈谈当时技术选型的取舍吗？

能谈谈明星出轨系统崩溃的原因是什么吗？有什么改进的计划吗？

顺便打听一下微博后端 Java 现在主要用 JDK 几，用 maven 还是 gradle

老大是否了解国内 go 的生态环境，go 会是下一代语言么？可否客观的说下。

新浪微博的用户关系是怎么维护的，如果一个人的粉丝非常多，怎么快速的找出他的互粉好友

@lhx2008 有使用 K8S 应用的案例吗，比如说用在数据库扩容上面

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

对于 devops 有什么优化上的建议么？好用么或者说需要注意什么？

@heart4lor 应届生如何向中间件方向发展，大佬能否给些建议呢？十分感谢~

去大公司，没了……

@axb 嗯嗯 确实是这样的，还是缺乏经验积累。

突发流量，比如明星出轨之类的，胡忠想老师的后台服务老是容易挂掉。微博的视频如何避免这种问题？

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


能谈谈明星出轨系统崩溃的原因是什么吗？有什么改进的计划吗？
不能，崩溃的不是我负责的系统，具体原因我也不清楚。

顺便打听一下微博后端 Java 现在主要用 JDK 几，用 maven 还是 gradle
jdk6-10 都有，maven 和 gradle 都有。

微博为什么限制部分用户在非登陆状态下的访问，防止爬虫吗？这些用户的微博会显示“找不到内容”。

微博消息箱是私信还是通知？如果是私信的话所有聊天记录都存储在云端有什么压力吗？

@caskeep 对于 devops 有什么优化上的建议么？好用么或者说需要注意什么？

我理解 devops 更多的是个概念，我们没有刻意的应用 devops，只是某天看到 devops 的资料的时候才发现：原来我们一直在做的这个实践叫 devops……

@JohnChiu 微博为什么限制部分用户在非登陆状态下的访问，防止爬虫吗？这些用户的微博会显示“找不到内容”。
我回答不了。

微博消息箱是私信还是通知？如果是私信的话所有聊天记录都存储在云端有什么压力吗？
私信。没明白你说的压力指的是什么？

@axb #56 聊天记录是怎样存储在数据库中的？因为聊天记录肯定比关注列表更多更复杂，想知道后端是怎么设计的

记得几年前好像有人说过微博私信用的是 xmpp，现在还是吗？这里面有遇到什么坑吗？

@Yoock 新浪微博的用户关系是怎么维护的，如果一个人的粉丝非常多，怎么快速的找出他的互粉好友

我不是专业做关系服务的，只提供个思路：

1 不管如何取数据，在数据量大的情况下，查找问题都会变成两个具体问题：1 如何哈希，2 如何建索引。
2 一份数据可以有多份索引，针对不同的业务场景也可以有异构的索引存储。
3 在满足 1，2 的情况下，索引问题会变成“如何维护数据一致性”的问题，但是这个问题解决起来要简单很多。

处理高并发有哪些难点？以前感觉这块挺神秘的，接触不到

@JohnChiu 聊天记录是怎样存储在数据库中的？因为聊天记录肯定比关注列表更多更复杂，想知道后端是怎么设计的

如果要设计一个存储聊天记录的系统，那只需要把标识聊天会话的 id 和对应的消息存起来就可以了吧，没理解具体难点是什么。

@Owenjia 记得几年前好像有人说过微博私信用的是 xmpp，现在还是吗？这里面有遇到什么坑吗？

从我那一代就不是了

@shikimoon 处理高并发有哪些难点？以前感觉这块挺神秘的，接触不到

能用缓存就用缓存
考虑并发场景下的一致性
在框架里做好断路器和保护机制
做压测和容量预估
加机器-.-

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

我是小白，问点不一定和技术沾边的问题

1.微博转发抽奖机制怎么排除机器用户的？怎么做到随机抽？

2.话说微博实名了后怎么注销？我有个实名了号上次按注销那里说的发手持身份证正反面到官方邮箱还不行，真不知道怎么办才好 号实名了我的信息现在想注销又注销不了，你有什么捷径吗？

老师您好，我问一个非技术问题，组里招应 java 届生更看重什么？

@CRUD 在公司业务没有多大并发量的情况下，要自己模拟学习高并发有什么好的建议吗

说实话，不太好搞。这问题就好像是“我现在身无分文，但是想今天就规划一下自己身价 10 亿之后的购物清单”一样，大部分情况下还是会受制于自己的经验。

我建议真要做就换个有高并发场景的平台。如果真的非要自己做，一方面可以看一些大厂技术大会的分享了解一下业务场景；一方面找一个现成的 app （比如微博），然后自己实现一个，自己压测看看极限在哪里。

大佬你现在自身的技术栈是怎么样的。3 年后端参考下。

@xwkkk 老师您好，我问一个非技术问题，组里招应 java 届生更看重什么？

我在另一个招聘贴里也说了（ t/613136 ）

我们招人的标准是好奇心=能力>经验，大部分人在上一份工作中只是遵照上级的要求写完代码，但是既没有了解更深的原理，也没有达到“用技术改变了什么”的程度。我认为这部分同学就算来了我这里，对于个人发展或者团队进步来说，不会有什么大的帮助（我们期望的是“更好”），因此卡掉了不少人。

校招其实也类似。

@QUIOA 1.微博转发抽奖机制怎么排除机器用户的？怎么做到随机抽？
这个机制我不了解。

2.话说微博实名了后怎么注销？我有个实名了号上次按注销那里说的发手持身份证正反面到官方邮箱还不行，真不知道怎么办才好 号实名了我的信息现在想注销又注销不了，你有什么捷径吗？
这个建议咨询客服……

后端技术的书籍，你有什么推荐的吗，不用太高级太深奥的，我参考下

再补充个问题

3.关于微博打击灰产。有个朋友做微博水军的（刷粉刷赞这种），像上次那个众所周知的星媛 app 事件就被微博安全团队联合警方捕了（据说靠这个半年赚了几百万。
是不是只要做不到那么大一般就不会出问题呢（指被官方报警联合调查）？

@cqxxxxxxx 大佬你现在自身的技术栈是怎么样的。3 年后端参考下。

我是属于那种“什么都会一点”的技术专家，如果单独说技术栈的话就太多了，列不下来。

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

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

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

@947211232 后端技术的书籍，你有什么推荐的吗，不用太高级太深奥的，我参考下

说实话入门书我很久没有看过了，光记着当年带我入门的书名大概是《 xx 网站架构设计》，封面是个小孩坐飞机的……

@QUIOA 这类问题我回答不了。

如何从技术上防止黑产养号、刷赞刷粉？

@QUIOA 如何从技术上防止黑产养号、刷赞刷粉？

跟黑产相关的问题我都回答不了，您就别问了……

@luckyrayyy 微博后端社招吗？大概需要什么技术能力和工作年限的人？

在招，可以参考之前发帖的正文和回复内容。/t/613136

微博有 golang 这块应用吗？

@shiny 微博有 golang 这块应用吗？

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

类似”点赞“这种业务，技术上或者模型设计上有什么经验可以分享下吗？

你所在部门 /团队的技术栈大概是怎样的？
比如说：编程语言、框架、中间件等等

谢谢~

很多公司要求的大数据高并发经验，在小公司工作的机会永远用不到的如果才能通过这种 offer

一个合格的 5 年后端要具备哪些能力？

哈哈，秦老师在微博吐槽没人投简历了。。

@CODEWEA 类似”点赞“这种业务，技术上或者模型设计上有什么经验可以分享下吗？

这个问题太宽泛了，我不知道你想问什么

@xiaowangge 你所在部门 /团队的技术栈大概是怎样的？
比如说：编程语言、框架、中间件等等

点我头像看我发的招聘帖，可以当技术栈演进来看……

大佬好，关注了您的微博，请问 估算一个对象的大小，这问题意义在哪？

@jason19659 很多公司要求的大数据高并发经验，在小公司工作的机会永远用不到的如果才能通过这种 offer

分两方面说，很多地方招聘（包括我这边）虽然更倾向于有高并发经验的人，但是这也不是个绝对的必选项。我的判断条件是“是否达到了所在平台的天花板”和“是否有持续进步的潜力”，大部分情况下，能把当前工作搞的很好的人，也能把高并发搞的很好。

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

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

@cinlen 一个合格的 5 年后端要具备哪些能力？

这问题有些宽泛，一线互联网公司的五年跟不知名公司的五年，完全不是一个概念。

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

@haosamax 大佬好，关注了您的微博，请问 估算一个对象的大小，这问题意义在哪？

没看懂你的问题，是说 jvm 里的大小还是序列化后的大小？前者一般是面试的时候考查对 vm 的理解，后者是缓存容量评估。

如果想往架构师方向发展（不做普通码农），应该是什么样的学习路线？我之前大致都了解了前后端的很多技术，但都不精细。我前段时间才发现自己在数据一致性上面忽略了很多东西；前几天才发现有个叫 DDD （领域驱动设计）的东西，学了以下发现以前写的思路很丑陋。所以有什么学习路线？（或者能不能给一些专有名词）

@Rwing 因为大厂用 java

@ebony0319 列表？

可否分享一下平常浏览的技术站点?

@Akiyu #95 楼主的博客有书单和站点分享的。

露珠提到的分布式文件系统同步与索引的问题，似乎在某种程度上与虚拟机内存回收算法类似，堆内存在线程间共享，而内存的回收从线程的角度看其实有点分布式的特点

你们团队有测试开发吗？如果有，请问他们都做些什么工作？他们的技术栈大概是怎么样的？

axb 大佬以前逛 nga 的吧？很久不上那个论坛了居然在你这儿看到了。


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

做到健壮，易读的，清晰的代码和简明的，维护和扩展想良好的设计其实挺不容易的。

国内不少程序员喜欢折腾很多高大上的东西，各种钻底层，谈概念，说起来头头是道。结果最后一看他写的代码，没有规范，并且大量的冗余逻辑和莫名其妙的，完全不考虑团队合作的设计，专门把很简单的事情搞的非常复杂，这种人太多太多。。。

个人感觉，可维护性，可扩展性，鲁棒性，不单单和技术有关，还和一个人的其他素养有关。