高并发的哲学原理 - Philosophical Principles of High Concurrency
小虾米高并发的哲学原理 - Philosophical Principles of High Concurrency
原文：Philosophical Principles of High Concurrency
高并发问题背后隐藏的一个哲学原理——找出单点，进行拆分。
读书笔记
基础设施并发：虚拟机与 Kubernetes（K8s）
镜像技术的核心——层
我们在删除 docker 镜像的时候，看到的 layer，就是层
软件架构本质上是软件维护团队的组织架构
如何搭建 SpringBoot 集群
在现有的工具支持下，实现 SpringBoot 集群是非常容易的，我之前就干过，多起几个应用实例，同时通过 Nginx 或者 Kong 进行反向代理并添加负载均衡即可。
重点是，我们在编写代码的时候就需要考虑好，我们的代码将来是需要做集群部署的，我们要以这个思想准备来写我们的代码，因此，不要使用单机缓存，使用分布式缓存，不要使用本地文件存储，使用分布式存储，等等等等。
这样，我们的应用就可以非常方便地进行横向地扩展，
突破编程语言的性能瓶颈
运行架构是指编程语言的设计者在设计语言时，为了实现某种功能或者解决某种问题，所采用的一种算法和数据结构的组合。这种组合决定了编程语言的性能、可扩展性和易用性等方面的特征。
这个说的很对，计算机硬件从单机角度来说其实就是计算和存储，那如何利用硬件提供的有限的计算能力（CPU）和存储（硬盘）来进行变成，就是编程语言做的事情，不通变成语言的差别，也就是在对计算能力和磁盘的使用方式上，也就是算法和数据结构。
一种编程语言，肯定是为了解决某种特定的问题而出现的，而为了解决特定的问题，其算法和数据结构的设计就必须有所倾向，所以编程语言从来都是偏科的，一种编程语言只能解决特定的问题，无法解决所有问题，所以编程语言没有银弹。而且不同编程语言的对比其实也是驴唇不对马嘴。
至关重要的 Web Server 软件
Nginx 与 epoll 的协同工作机制 | 高并发的哲学原理
epoll 的本质：9.2 I/O 多路复用：select/poll/epoll | 小林 coding
使用软件定义网络（SDN）技术搭建大规模负载均衡集群
其实我没看明白 SDN 实现负载均衡，跟 Nginx，Kong 实现负载均衡有什么差别。
通过 Keepalived 实现应用的高可用，比如可以实现 MySQL 的高可用：mysql 学习-mysql8.0 配置双主复制+keepalived 实现高可用架构 - 天翼云
MySQL InnoDB 存储引擎详解
对于采用 b+ 树做索引的数据库来说，我们应该控制单行数据量，单行数据量不宜太大。
主键 ID 不易太大
四代分布式数据库的变迁
Paxos 协议：这个协议古老而复杂，以后有需要再去学习
raft 分布式一致性协议，distributed consensus protocol
官网：raft
Raft 协议的动画演示，做的真的很好
Raft 协议的论文：raft-zh_cn/raft-zh_cn.md at master · maemual/raft-zh_cn · GitHub
Raft 协议的一些应用：
基于 raft 协议的分布式缓存 Hazelcast：GitHub - hazelcast/hazelcast: Hazelcast is a unified real-time data platform combining stream processing with a fast data store, allowing customers to act instantly on data-in-motion for real-time insights.
Kafka 2.8 版本：开始放弃 Zookeeper，转向使用 Raft 协议来实现分布式一致性
Gossip 协议：病毒式传播信息实现最终一致性。
秒杀系统的两大利器——缓存与队列
缓存可以削“读”的峰，队列就是拿来削“写”的峰的。
说的真好
真实的秒杀流程
无限容量架构——站在地球表面
分布式和微服务，是两个概念，这两个概念是正交的，如果非要说一下区别的话，就是，分布式系统，更多的应用一个系统下，即多台服务器对外提供同一种服务，这多台服务器之间的协调问题，就是分布式系统需要解决的问题。
而微服务，则是对业务系统进行拆分，拆分成多个相互独立的子系统，什么叫独立呢？从网关，web 服务器，到中间，数据库都是独立的，这些独立的子系统内部可以有多台服务器（分布式系统），也可以只有一台服务器。
微服务的拆分，本质上是为了拆分单点，拆分网关单点，拆分数据库单点，等等等等
概述 | 高并发的哲学原理中说，如果两个 API 的数据落到同一张表上，那它们两个就属于同一个系统，如果不是，那他们就是两个系统，可以拆分成两个微服务
微服务背后的哲学
既然我们不能把拼多多和淘宝的系统称作一个系统，那么，在拼多多和淘宝系统内，肯定还可以基于类似的逻辑继续拆分：
在大量调用的 API 中，一次携带了数据写入的请求一定只会对单个微服务进行写入，但会对多个微服务进行数据读取
如果某个头部 API 请求会对两个微服务系统进行写入，那说明微服务的划分出了问题，需要调整系统结构划分
地理上被隔开的两个人，在系统内还真没什么机会需要相互查询对方的数据，这就是我们能基于地理位置对应用和数据库进行分区的现实原因
将一个大系统拆成不需要实时相互通信的多个小系统，可以获得线性的性能提升。
在目前的实践中，从数据层面进行地理位置的拆分是一种接近无限容量的分布式系统设计方案，这也是目前头部互联网公司都在使用的一种方案。
总结
我们之前在学习数据库的时候，了解到 DB 一共就三层：存储、计算、网络。这也是云计算的三大基础组件。其实这三层可以拓展到任何大型分布式软件。
并发哲学这本书讨论的单点拆分，其实就是从计算，存储，网络这三个层面进行拆分。
-
第二部分：计算资源高并发，对应计算
-
第三部分：网络资源高并发：对应网络
-
第四部分：数据库高并发：对应存储