概述
分布式系统（Distributed System）是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。
为了性能的提升，当单个节点的处理能力无法满足日益增长的计算、存储任务，且硬件的提升高昂到得不偿失的时候，我们才考虑用分布式系统。因为分布式系统要解决的问题本身就是和单机系统一样的，而由于分布式系统多节点、通过网络通信的拓扑结构，会引入很多单机系统没有的问题，为了解决这些问题又会引入更多的机制、协议，带来更多的问题。
Partition和Replication是解决分布式系统问题的一个组合，很多具体的问题都可以用这个思路去解决。当然也会引入更多的问题，比如为了可用性与可靠性保证，引用了冗余（复制集）。有了冗余，又需要考虑各个副本间的一致性问题。正如CAP、FLP等理论，在分布式系统中，没有最佳的选择，只有最合适的选择。
分布式系统的挑战：
- 异构的机器与网络：分布式系统中的机器配置不一样，其上运行的服务也可能由不同的语言、架构实现，因此处理能力也不一样；节点间通过网络连接，而不同网络运营商提供的网络的带宽、延时、丢包率又不一样。
- 节点故障：当节点数目达到一定规模时，出故障的概率就变高了。分布式系统需要保证故障发生的时候，系统仍然是可用的。
- 不可靠的网络：节点间通过网络通信，而网络是不可靠的。
分布式系统特性与衡量标准：
- 透明性：分布式系统的最高境界是用户根本感知不到这是一个分布式系统。
- 可扩展性
- 可用性与可靠性
- 高性能
- 一致性
一个大型网站包含诸多组件，每一个组件都是一个分布式系统，比如分布式存储就是一个分布式系统，消息队列就是一个分布式系统。
一些概念：
负载均衡：
- Nginx
- LVS
webserver：
- Java：Tomcat，Apache，Jboss
- Python：gunicorn、uwsgi、twisted、webpy、tornado
service：
- SOA、微服务、spring boot，django
容器：
- docker，kubernetes
cache：
- memcache、redis等
协调中心：
- zookeeper、etcd等
rpc框架：
- grpc、dubbo、brpc
消息队列：
- kafka、rabbitMQ、rocketMQ、QSP
实时数据平台：
- storm、akka
离线数据平台：
- hadoop、spark
dbproxy：
- cobar也是阿里开源的，在阿里系中使用也非常广泛，是关系型数据库的sharding + replica 代理
db：
- mysql、oracle、MongoDB、HBase
搜索：
- elasticsearch、solr
日志：
- rsyslog、elk、flume
请求过程
用户使用Web、APP、SDK等通过HTTP、TCP连接到系统。在分布式系统中，为了高并发、高可用，一般都是多个节点提供相同的服务，所以需要考虑负载均衡。
通过负载均衡找到一个节点后，接下来就是真正处理用户的请求了，请求有可能简单，也有可能很复杂。如果有缓存，则需要考虑分布式缓存，如果缓存没有命中，那么需要去数据库拉取数据。
假设服务A需要调用服务B的服务，首先两个节点需要通信，网络通信都是建立在TCP/IP协议的基础上，但是，每个应用都手写socket是一件冗杂、低效的事情，因此需要应用层的封装，因此有了HTTP、FTP等各种应用层协议。当系统愈加复杂，提供大量的http接口也是一件困难的事情。因此，有了更进一步的抽象，那就是RPC。
一个请求可能包含诸多操作，即在服务A上做一些操作，然后在服务B上做另一些操作，这就涉及到分布式事务的问题。
分布式系统中有大量的服务，每个服务又是多个节点组成，一个服务要想找到另一个服务的某个节点就需要服务注册与发现了。
用户请求操作会产生一些数据、日志等信息，其他一些系统可能会对这些消息感兴趣，这里就抽象出了两个概念，消息的生产者与消费者。那么生产者怎么讲消息发送给消费者呢，RPC并不是一个很好的选择，因为RPC肯定得指定消息发给谁，但实际的情况是生产者并不清楚、也不关心谁会消费这个消息，这个时候就需要消息队列了。
上面提到，用户操作会产生一些数据，这就催生了分布式计算平台用来处理这些海量的数据。
最后，用户的操作完成之后，用户的数据需要持久化，但数据量很大，大到按个节点无法存储，这时就需要分布式存储。