Create 200914-note-service-side.md

200914-note-service-side.md

@@ -0,0 +1,151 @@
+笔记
+
+源帖：[突然闲下来没事干，开个贴回答互联网后端技术问题](https://v2ex.com/t/613460?p=1)
+
+- 怎么做到增加机器能线性增加性能的？
+
+	线性扩容有两种情况，一种是“无状态”服务，比如常见的 web 后端；另一种是“有状态服务”，比如 mysql 这种数据库。
+
+	对于无状态服务，一般只要解决了“服务发现”功能，在服务启动之后能够把请求量引到新服务上，就可以做到线性扩容。常见的服务发现包括 DNS 调度（通过域名解析到不同机器）、负载均衡调度（通过反向代理服务转发到不同机器）或者动态服务发现（比如 dubbo ），等等。
+
+	对于有状态服务，除了要解决服务发现问题之外，还要解决状态（数据）迁移问题，迁移又分两步：先是数据拆分，常见的都是用哈希或者一致性哈希把数据打散。然后是迁移，常见的办法有快照和日志两类迁移方式。也有一些数据库直接实现了开发无感知的状态迁移功能，比如 hbase。
+
+- 做「你关注的某某人评论了某某人」之类的和几度人际关系相关的复杂功能的时候有没有遇到哪些性能上可能的问题。
+
+	这肯定是有性能挑战的，比如“你关注的人也在关注”、“你关注的人最近发的微博”等等，都可以理解是二度关系。主要挑战点是数据的扇出量会比较大，我关注了 1000 人，这 1000 人又每人关注了 1000 人，那就是要 100 万的数据做处理。解决办法要么是减少扇出（比如限制关注人数量），要么是离线算数据，在线取结果。
+
+- 视频存储和提供有什么难点嘛？
+
+	视频存储和播放难点要分开说。
+
+	对于分布式文件系统来说，有几个难点。
+	一个是文件大带来的执行效率，比如用户上传一个 10G 的文件，要 1 秒之后立刻能够访问，需要做一些性能优化的策略
+	一个是可用性，在某台机器宕机之后不能影响用户数据，需要有数据迁移和冗余的策略。
+	一个是文件多带来的元信息膨胀，分布式文件系统都要保存每个 key 的元信息（比如存在哪台机器上），当文件超过几百亿之后也会带来元信息存取的压力。
+
+	而播放一方面是整体缓存架构和调度策略的选择，另一方面的难点主要是对于网络（在目前场景下，主要是 tcp 协议）的理解、对协议（比如 http/http over quic ）的理解和策略的选择。
+
+	当然，在国内 isp 环境下，更多的还是与人斗，其乐无穷。
+
+- 分布式事务这块是怎么处理的呢？是由业务系统去做一致，幂等之类的保证吗？还是有统一的中间件或框架呢？
+
+	微博这边的一致性要求并不高，一般是通过幂等性和常规的乐观、悲观锁实现的，分布式事务（至少在我这里）用的不多。
+
+- 视频类的后端开发和其他图文为主的社区产品后端开发，架构、技术选型上有哪些不一样的地方？
+
+	从整体的角度来抽象看，要做的东西其实差不多，都会有增删改查，然后内容理解+推荐；视频特殊一些的地方是有视频编解码。
+
+	具体技术选型来说的话，业务上的增删改查都差不多，但是视频存储都是对象存储服务而非关系型数据库；视频方向的内容理解更多的偏向深度学习的实现；视频编解码是一门独立的专业，不过由于太耗计算资源所以还要配合着调度系统一起实现。
+
+- 怎么做才能做到不同地区，用户播放视频都比较流畅？会用到类似 CDN 的部署架构？
+
+	如果往深了说，流畅是几方面的综合结果，包括视频体积、CDN 部署、播放调度、防劫持、播放调度、防劫持等等。
+
+	对于你说的不同地区来说，最重要的方面有两个：一个是 CDN 部署和调度情况，尽量让用户访问边缘节点；然后是防止劫持，一般流量被劫持后都不可避免的性能变差……
+
+- 应用服务器的数据库连接池应该设多大？看了一篇译文 https://www.jianshu.com/p/a8f653fc0c54 的观点是"连接数 = ((核心数 * 2) + 有效磁盘数)", 不知道实际一般是不是这样计算？
+
+	我没太看懂你的问题，到底是数据库服务的连接池，还是应用服务连接数据库的连接池？文章里我简单扫了一眼，似乎是后者
+
+	不过无论哪个连接池，核心问题还是“同一时间内，需要同时请求的数量”，这个其实就是个数学公式，类似“这条路上每天要跑 1000 辆车，每辆车跑个来回要 10 分钟，那么路建多宽合适”。按我的经验，连接数多设一点不会有太多问题（除非设的数量太夸张把系统连接数耗尽了），而设少了，在系统负载变高的时候就会出现非常明显的排队现象，这对服务性能的影响更大一些。
+
+- 在系统或功能模块设计阶段是如何考虑系统的扩展性的呢？是快速原型，实现，上线，后续迭代升级，还是说会在一开始就做一些复杂的设计？在这方面是怎么作取舍呢？
+
+	设计阶段要考虑的首先是“系统哪些功能是必不可少并且需要快速验证的”，然后是“系统 2 年以内有可能会有什么变化”，觉着不好设计的原因还是设计少了，踩的坑不够多。经验多了，就没这类问题了。
+
+- 一个人有几千万个关注，这种数据结构怎么存呢？
+
+	存不是问题，你用个普通 mysql，只要哈希的够多，都能存的了。难的问题是“怎么取”，这个要看业务场景。
+
+- 新浪微博的用户关系是怎么维护的，如果一个人的粉丝非常多，怎么快速的找出他的互粉好友？
+
+	我不是专业做关系服务的，只提供个思路：
+
+	1. 不管如何取数据，在数据量大的情况下，查找问题都会变成两个具体问题：1 如何哈希，2 如何建索引。
+	2. 一份数据可以有多份索引，针对不同的业务场景也可以有异构的索引存储。
+	3. 在满足 1，2 的情况下，索引问题会变成“如何维护数据一致性”的问题，但是这个问题解决起来要简单很多。
+
+- 处理高并发有哪些难点？
+
+	- 能用缓存就用缓存
+	- 考虑并发场景下的一致性
+	- 在框架里做好断路器和保护机制
+	- 做压测和容量预估
+	- 加机器
+
+- 老师您好，我问一个非技术问题，组里招应 java 届生更看重什么？
+
+	我们招人的标准是好奇心=能力>经验，大部分人在上一份工作中只是遵照上级的要求写完了代码，但是既没有了解更深的原理，也没有达到“用技术改变了什么”的程度。我认为这部分同学就算来了我这里，对于个人发展或者团队进步来说，不会有什么大的帮助（我们期望的是“更好”），因此卡掉了不少人。
+
+- 大佬你现在自身的技术栈是怎么样的。3 年后端参考下。
+
+	换个回答方向，说一下我认为自己的技术强项吧。
+
+	一个是系统设计能力，能够设计微博这种用户和流量规模的后端服务。
+	一个是对操作系统、网络和 VM 的理解，能够排查复杂性能问题。
+	一个是业务方面的能力，包括通讯直播视频和社交媒体相关业务和对应技术（消息推送、视频编码、文件存储，等等）
+
+	总结下来的话，就是基础知识+架构经验+领域知识吧。
+
+- 很多公司要求的大数据高并发经验，在小公司工作的机会永远用不到的如果才能通过这种 offer
+
+	分两方面说，很多地方招聘（包括我这边）虽然更倾向于有高并发经验的人，但是这也不是个绝对的必选项。我的判断条件是“是否达到了所在平台的天花板”和“是否有持续进步的潜力”，大部分情况下，能把当前工作搞的很好的人，也能把高并发搞的很好。
+
+	另一方面，我一直认为能去大厂还是尽可能的去大厂，毕竟大厂能带来的经验和提升很多小公司确实没有。通过自学能储备一些知识，网上的教程也有不少，不过经验的差距很难解决。
+
+	简单来说，把自己想象成应届生，工作几年没有高并发经验和应届生没有工作经验面临的状况是类似的。
+
+- 一个合格的 5 年后端要具备哪些能力？
+
+	这问题有些宽泛，一线互联网公司的五年跟不知名公司的五年，完全不是一个概念。我只说一线互联网公司的五年，基本上应该是小组长，能够独立设计日活百万级别的后端系统架构，在开发规范和效率方面能够指导初级工程师和工作。此外还有复杂问题的分析和解决能力。
+
+- 如果想往架构师方向发展（不做普通码农），应该是什么样的学习路线？我之前大致都了解了前后端的很多技术，但都不精细。我前段时间才发现自己在数据一致性上面忽略了很多东西；前几天才发现有个叫 DDD （领域驱动设计）的东西，学了以下发现以前写的思路很丑陋。所以有什么学习路线？（或者能不能给一些专有名词）
+
+	我觉着架构师主要是靠经验，其次才是学习。架构师的核心价值是在某个场景下构建合理的应用，如果没有架构的应用场景的话，那即使学了一堆名词，也只能硬套概念而不是解决问题，我觉着意义不大。但如果就是想了解这些名词的话，各种技术公众号或者微博关注一波，每天一大堆在上面扯名词的，有些名词我都不认识……
+
+- 请问大佬，如果想重试大数据开发的话，平时应该多关注哪些技术栈呢，从服务端开发转过去有哪些地方需要了解提升的？
+
+	大数据开发这个职位挺缥缈的……我不清楚你说的大数据开发是指的数据分析、数据中间件、有大数据场景的后端应用还是什么别的。
+
+	第一个，一般就是流式处理框架，Hadoop 全家桶之类的数据处理框架。第二三个，跟普通后端开发没啥本质区别。
+
+- 请教两个直播相关的问题
+
+	1.用户的关注列表分页拉取时，如何把正在直播的主播前置到列表
+
+	假设正在直播的主播不多，可以单独存正在直播的主播，插到关注列表前面。
+
+	2 主播的粉丝量很大时，开播如何及时推送给粉丝
+
+	1 想办法并行取粉丝关系，并行推送 2 优先推送核心用户 3 改成拉取模式，实时获取当前主播的直播状态
+
+- 后端扩容有什么好的方案和建议呢？
+
+	1，数据库变大，需要动态增加机器，怎样一种方案可以无感知增加？
+	要么是提前做逻辑分表，容量瓶颈之后把逻辑表做物理迁移。或者干脆用 hbase 这种天然扩容无感知的数据库。
+
+	2，数据量变大，查询效率如何维持？
+	提前做容量预估
+
+	3，老数据的删除，我们项目上有，不知道大佬的项目中怎么处理？
+	对 mysql 来说就是按月分表，定期删除过期表。对 hbase 之类的设个 ttl
+
+- 微博存在中台部门吗，各个组之间 RPC 调用是 dubbo 吗
+
+	我负责的部门就叫视频中台，RPC 调用是微博自研的 motan https://github.com/weibocom/motan
+
+- 分布式数据库是如何进行数据同步的,对高并发大数据来说,除了主从复制还有其他方法吗?另一个问法就是有哪些可以参考的技术等等.谢谢大佬.
+
+	要么类似 mysql 的异步主从，要么类似 hbase 冗余写多份。写多份的方案从简单的客户端多写，到通过共识算法达成一致都有，建议搜索引擎里直接列上几个数据库名字，比如 mysql hbase tidb，应该就能搜出一堆资料
+
+- “有两个百万条数据的表以及三张万以内数据表，取数据的时候不可避免要 join”
+
+	如果能改表结构的话，把索引和内容分开存，其实百万级的数据全放内存里都没多少容量。如果非要 join，要么降低 join 的数据规模，要么提前算好数据，要么把能缓存的数据（比如那 3 张表）缓存起来，尽量降低查询时的磁盘消耗
+
+- 直播聊天室、弹幕、送礼物消息和特效展示这类消息群发，用到后端的技术栈是什么样的？
+
+	最核心的是实现网络层推送的框架，比如 netty，其他跟普通后端开发没啥区别。
+
+其他
+
+paxos、raft 分布式一致性算法：Paxos算法详解：https://zhuanlan.zhihu.com/p/31780743