石杉的架构笔记-阅读记录【持续更新...】

最近发现一个宝藏博主：石杉的架构笔记。博文质量很高，打算通篇阅读一下。这里针对每篇博文大致做一下内容简介以便后面快速检索以及查漏补缺。
需要提示的是：值得复看指数并不是文章质量，而是我个人基于我当前的知识储备认为文章内容对我的帮助。但是这一点对每个人都是不一样，不要作为参考。

系统设计

序号	博客	简介	关键词	值得复看指数
1	支撑日活百万用户的高并发系统，应该如何设计其数据库架构？【石杉的架构笔记】…	16C32G数据库并发量尽量不要超过2000。分库分表缓解压力。读写分离：通过不断挂从库来分离并发量，避免频繁扩容（但是要注意数据一致性场景）。 一般来说8C16G的MySQL服务器一般可以抗下1000-2000的并发，16C32G的一般可以抗2000-3000，但是这些也和带宽，磁盘IO，内存，CPU，以及代码fen不fen有关	MySql, 分库分表，读写分离	⭐⭐⭐
2	面试一线互联网大厂？那这道题目你必须得会！【石杉的架构笔记】	设计一个消息中间件需要考虑的问题：【接到的消息 接消息的ack】【接到的消息怎么存，磁盘不可能存在同一个文件中，也不能每次都写磁盘】【分布式，扩缩容】【消息备份，重新负载均衡】【消费消息，怎么按投递给消费者，消费消息的ACK】。(根据这个总结设计思路：数据怎么来，数据怎么存，数据怎么走。怎么保证三高：高并发，高可用（包括稳定服务与数据不丢失），高性能)除此之外文章内还附了两篇关于RabbitMQ如何保证消息不丢失的文章	MQ，系统设计	⭐⭐⭐
3	【Java进阶面试系列之一】哥们，你们的系统架构中为什么要引入消息中间件？	消息中间件的作用： 系统解耦（一拖多）， 异步调用（某环节特耗时），消峰（瞬时流量）， 压力分散	MQ	⭐⭐
4	【Java进阶面试系列之二】：哥们，那你说说系统架构引入消息中间件有什么缺点？	引入MQ缺点：可用性降低(引入新组件也意味着引入风险)，稳定性降低（接口幂等，高积压后的服务恢复，数据一致性（重试）	MQ	⭐
5	最终一致性分布式事务如何保障实际生产中99.99%高可用？	这篇文章写的比较乱。前面大概讲的就是利用MQ本身的机制以及DB的事务来实现投递与db的一致性。后面又列了一个利用Redis解决MQ故障的降级方案以及注意点	MQ	⭐
6(亿流量大考)	亿流量大考（1）：日增上亿数据，把MySQL直接搞宕机了… 亿流量大考（2）：开发一套高容错分布式系统 亿流量大考（3）：不加机器，如何抗住每天百亿级高并发流量？ 亿流量大考（4）：自研ES+HBase+纯内存的高性能毫秒级查询引擎 亿流量大考（5）：百亿流量全链路99.99%高可用架构最佳实践	一个系统从0到百亿流量的迭代过程，以及如何通过各种技术方案保证高并发，高可用，高性能的。 归根结底： 读写分离，分库分表， 冷热分离， 进行缓存，拆分任务单元，分布式，限流，消峰，主备，负载均衡等可以总结出来的方案。 文章中你看到一些解决方案后也许会想，这不就是**吗。但是重要的点不在于这里，没有一个方案是万能的重要的点在于面对这个问题是否能根据自己的数据特性设计出匹配的的实施方案。 看了这个迭代过程会给后续的方案涉及带来启发。 系统迭代以及升级不是一蹴而就的，而是随着业务的迭代，先找出来目前的瓶颈，再解决瓶颈的一个过程。	系统设计	⭐⭐⭐⭐⭐
7	设计一个可拔插的 IOC 容器	cicada开发者写的一篇文章，主要讲了他怎么扫描类以及怎么做一个热插拔的IOC容器。内容倒是其次，内部一个开源开发者的心理活动可以看看。	IOC,开源开发	⭐⭐
8	如何设计一个百万级的消息推送系统	一个消息推送（在线聊天）系统设计所要考虑到的东西：鉴权，长连接(心跳)，服务注册发现，负载均衡(分布式路由)，推送路由，消息解耦，应用监控，日志处理。每个方面都提了一嘴，但是每个方向都没细讲，需要一定的知识储备。适合设计系统事件作为参考。 Netty 是一个基于NIO的客户、服务器端的编程框架。一致性哈希。	系统设计	⭐⭐⭐?
9	老司机生产实践经验：线上系统的JVM内存是越大越好吗？	JVM内存要根据其所承载的应用来判定。如果是一个JAVA服务，那么可能大点好。但是如果是Kakfa或者Es这种性能主要依赖OS cache，JVM只是为其提供了运行环境的。则JVM内存过大反而会占用OS Cache的空间导致性能变差。针对类似应用，给JVM比如6GB或者几个GB的内存就可以了（具体压测决定），机器其它程序也会占用几个G的内存	系统设计	⭐⭐⭐⭐⭐
10	从团队自研的百万并发中间件系统的内核设计看Java并发性能优化	双缓冲机制可以不间断的写，且让刷磁盘的低效不影响到写。 如何实现一个高并发的双缓冲机制：分片机制 + 分段加锁机制。 Buffer的flush本身就有lock机制，因此不需要再额外加锁。	双缓冲，高并发，分段锁	⭐⭐⭐

分布式

序号	博客	简介	关键词	值得复看指数
1	高阶Java开发必备：分布式系统的唯一id生成算法你了解吗？	分布式下全局唯一ID的生成方案：单库，uuid,业务拼接，雪花算法	分库分表，分布式	⭐⭐
2	用小白都能看懂的大白话告诉你：什么是分布式计算系统？	简单的举例描述了一下什么是分布式计算	大数据,分布式	⭐
3	兄弟，用大白话给你讲小白都能看懂的分布式系统容错架构	分布式存储设计根本就是数据分片存储 、多副本冗余、宕机感知、自动副本迁移、多余副本删除，这套机制	分布式，系统设计	⭐⭐⭐

中间件

MQ

序号	博客	简介	关键词	值得复看指数
RabbitMQ-1	如何保证消息中间件全链路数据100%不丢失（1）	这个系列的前言，就是描述一下场景，内容没什么	RabbitMQ	半⭐
RabbitMQ-2	如何保证消息中间件全链路数据100%不丢失（2）	简单讲了下RabbitMQ的ACK机制，和RocketMQ大同小异。分为手动ACK和推送即成功两种。手动ACK显式返回成功还是失败，ACK是基于channel的，channel只能Ack从这个通道来的delivery tag（类似于Message ID）。事实上目前集成的MQ组件都是业务逻辑处理成功才会ACK。	RabbitMQ	⭐⭐
RabbitMQ-3	消息中间件如何实现消费吞吐量的百倍优化？	介绍了一下RabbitMQ的prefetch count概念（一个channel中unack的最大数目），过大会导致消费者崩溃，又因为重发机制引起雪崩。过小导致消费者服务的吞吐量极低。官方建议prefetch count一般设置在100~300之间。RabbitMQ的ack是异步的，也就是你调了ACK方法之后不会马上ACK，具体ACK时机由RabbitMQ决定。主要是RabbitMQ的消费端需要考虑的问题：（手动ack、处理失败的nack）（这两个如果不是用原生的而是用集成的，一般都处理过了）、prefetch count的合理设置	RabbitMQ	⭐⭐⭐
RabbitMQ-4	高并发场景下，如何保证生产者投递到消息中间件的消息不丢失？	介绍了一下RabbitMQ的confirm机制，confirm和ACK一样具有高延迟性（所以尽量不要串行，性能很差）。 以及通过ConfirmListener进行投递ack和nack的处理。并且需要制定自己的业务扫描机制进行数据重发。	RabbitMQ	⭐⭐⭐
Kafka-1	面试官：消息中间件如何实现每秒几十万的高并发写入？	大概讲了一下Kafka高效的关键：顺序写，OS缓存写。以及零拷贝	Kafka	⭐
Kafka-2	面试官：请谈谈写入消息中间件的数据，如何保证不丢失？	Kafka的Partition和ISR机制保证消息不丢失。ISR机制可以看一下。也是一个在分布式数据存储下消息不丢失的巧妙设计。至少一主一从成功才算真的成功	Kafka	⭐⭐⭐
Kafka-3	生产实践总结】支撑百万连接的系统应该如何设计其高并发架构？	Kafka用多路复用IO的方式来处理来自生成者消费者的链接。这里再次提醒多路复用IO是一种IO模型，NIO只是JAVA上的实现。你可以在任何需要IO的地方采用这种模型来复用工作线程处理多路链接。不是说一定要是Java才行。	Kafka	⭐⭐

ES

序号	博客	简介	关键词	值得复看指数
1(ES-1)	ES性能优化原理揭秘！初看一脸懵逼，看懂直接跪下。。。	为什么ES只应该存储检索数据，不应该存非索引数据。应用内存-JVM内存=es可用内存。一台ES存多少数据才合适。为什么数据多了会变慢。ES深度分页怎么处理（和MySQL分页差不多）	Es	⭐⭐⭐⭐⭐
2(ES-2)	一文给你搞定Elasticsearch技术扫盲！	提了一下倒排索引，以及ES中index和document的概念。此外借着ES讲了一下分布式的基础理念：就是数据分片和主备那一套	Es	⭐⭐

注册中心与协议

序号	博客	简介	关键词	值得复看指数
1	尴尬了！Spring Cloud微服务注册中心Eureka 2.x停止维护了咋办？	因为Eureka停止维护，所以大概提了一下另外一个注册中心：Consul。以及Consul的一些特性。Consul不同于Eureka的集群同步，采用是分片加热备的理念：保证强一致与可用性。此外Consul还支持简单的KV数据存储，并且为服务调用提供了权限功能。	Consul，注册中心	⭐⭐⭐
2	如何优化Spring Cloud微服务注册中心架构？	介绍了一下服务中心，服务注册，服务发现的概念。简单提了一下Consul的Raft协议。以及Consul	Consul，注册中心	⭐⭐
3	【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？	Eureka和服务端的交互过程，重点在于Eureka的多级缓存机制保证注册表的高效:ReadWriteCacheMap存在的意义是作为二级缓存，因为ReadOnlyCacheMap到期是全部清除的，ReadWriteCacheMap存在的意义就是在ReadOnlyCacheMap全部清除后，不让所有的流量都达到注册表上面，那些没变更的由ReadWriteCacheMap拦截，让这些不必受注册表可能存在的变更（扩缩容）影响。	Eureka注册中心	⭐⭐⭐

微服务

序号	博客	简介	关键词	值得复看指数
1	拜托，面试请不要再问我Spring Cloud底层原理	主要是Spring Cloud的各个组件和定位	微服务，Cloud	⭐
2	【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战	无限制的设置超时和重试时间，长响应接口导致hystrix被拖垮的解决实例。Cloud的重试和幂等	微服务，接口雪崩	⭐⭐⭐⭐
3	微服务架构如何保障双11狂欢下的99.99%高可用	hystrix线程池大小怎么设，超时时间怎么设，服务时间，超时时间，线程池大小之间的关联，注意他这里的超时是hystrix的超时，超时之后就直接返回了，而不是ribbon的超时，超时重试是属于ribbon的机制。所以hystrix参数设置不需要考虑重试的成本。这里也体现了，hystrix的超时要比ribbon的厂，不然ribbon还没返回，hystrix直接给超时返回了，就尴尬了。另外此文还提了一下降级。	微服务，hystrix，参数设置，降级	⭐⭐⭐⭐⭐

Java基础

序号	博客	简介	关键词	值得复看指数
1	哥们，你真以为你会做这道JVM面试题？	一道JVM类加载及初始化流程的题目。从JVM类加载过程缕这道题比较好理解（常量代码块-常量初始化-构造-静态代码块-静态变量初始化）有些像new String(“s”)生成几个对象一样。是否重要以及值得看自行评价	JVM	⭐

职场,面试与个人提升

序号	博客	简介	关键词	值得复看指数
1	【非广告，纯干货】三四十岁的大龄程序员，应该如何保持自己的职场竞争力？	职业规划的几个方向：技术核心，业务核心，管理岗以及转型	职场	⭐⭐⭐
2	【真实案例分享】面对BAT大厂的竞争对手时，小公司Java工程师是如何败北的？	只能说大厂背书就是好	职场	⭐
3	【架构师成长必备】如何阅读一个开源项目的源码？	怎么读一个源码，如果有读源码的想法的话可以看一下	个人提升	⭐⭐⭐⭐
4	【纯干货分享】小公司出身的我，是如何拿下知名独角兽公司offer的？	面经分享，可以看看需面试时所需要关注的知识点以及心态	职场，面试	⭐⭐

算法

序号	博客	简介	关键词	值得复看指数
1	几道和「堆栈、队列」有关的面试算法题	有效的括号，用两个栈实现队列，栈的压入、弹出序列，包含 min 函数的栈 几个典型的涉及栈的算法题，没什么好说的。	算法	⭐
2	拜托，面试请不要再问我这么沙雕的动态规划算法题！	一个动态规划题目，leetcode的877. 石子游戏 ,力扣题解中三叶大神的要比官解更容易理解。可以训练一下动态规划的知识。这种大区间结果依赖于小区间结果的情况都可以考虑下动态规划	算法	⭐⭐⭐