分布式系统的简单理解
思考：尽可能说出自己的理解，用大白话讲述，而不是复制粘贴资料。
重点：分布式事务，分布式搜索，分布式缓存，分布式锁，分布式消息队列，分布式session，分库分表
集群、分布式
1.集群：同一个业务，部署在多个服务器上(不同的服务器运行同样的代码，干同一件事)
2.分布式：一个系统分拆多个子模块，部署在不同的服务器上(不同的服务器，运行不同的代码，协同完成功能)
3.当今是个分布式、集群、云计算等名词满天飞的时代。造成这种局面的一个重要因素就是，单一机器的处理能力已经不能满足我们的需求，不得不采用由多台机器组成的服务集群。服务集群对外提供服务的过程中，可以分解处理压力，在一定程度上打破性能瓶颈，并提高服务的可用性（不会因为一台机器宕机而造成服务不可用）。
4.架构师的技术升级要点：用两个字来描述：集群，用三个字：分布式，再用多点的文字：把海量的流量和数据合理分摊到数量合适的机器上。
想明白这点，后面就能知道该学哪些了，比如流量分摊时得负载均衡，存储海量数据时得靠数据库集群，或分库分表，为了防止单点失效，得设计冗余系统，系统间通讯时得用消息中间件，不能让每次请求都走后台，所以可以搭建缓存，单个缓存容易失效，所以可以搭建分布式缓存，为了监控性能，所以得上一些监控措施，比如监控JVM，监控数据等的，为了等看日志，所以得上一些日志组件。等等。
参考资料：https://blog.csdn.net/qq_24047659/article/details/86731850
5.Partition(分区)和Replication(副本)是解决分布式系统问题的一记组合拳，很多具体的问题都可以用这个思路去解决。但这并不是银弹，往往是为了解决一个问题，会引入更多的问题，比如为了可用性与可靠性保证，引用了冗余（复制集）。有了冗余，各个副本间的一致性问题就变得很头疼，一致性在系统的角度和用户的角度又有不同的等级划分。如果要保证强一致性，那么会影响可用性与性能，在一些应用（比如电商、搜索）是难以接受的。如果是最终一致性，那么就需要处理数据冲突的情况。CAP、FLP这些理论告诉我们，在分布式系统中，没有最佳的选择，都是需要权衡，做出最合适的选择。
分布式一致性
1.CAP理论：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中两项。
C：数据一致性(consistency) ， 所有节点拥有数据的最新版本。其中，一致性又分为强一致性、弱一致性、最终一致性。
A：可用性(availability) ，数据具备高可用性
P：分区容错性(partition-tolerance)，容忍网络出现分区，分区之间网络不可达。
2.分布式一致性。数据的一致性模型可以分成以下 3 类：
- 强一致性：数据更新成功后，任意时刻所有副本中的数据都是一致的，一般采用同步的方式实现。
- 弱一致性：数据更新成功后，系统不承诺立即可以读到最新写入的值，也不承诺具体多久之后可以读到。
- 最终一致性：弱一致性的一种形式，数据更新成功后，系统不承诺立即可以返回最新写入的值，但是保证最终会返回上一次更新操作的值。
分布式事务
1. 分布式事务：2PC。3PC。
2.BASE理论。
3.概念：分布式事务是指会涉及到操作多个分布式节点(服务器)上的多个数据库的事务。如果想让分布式部署的多台机器中的数据保持一致性，那么就要保证在所有节点的数据写操作，要不全部都执行，要么全部的都不执行。
4.分布式事务和分布式一致性的关系：为了满足分布式一致性，多节点上的数据库操作要保证分布式事务。
5.分布式事务的例子：比如，进行一次下单操作，在A节点的库存模块对应的库存表会减少一个库存，而在B节点的订单模块中的订单表会增加一条订单，这个就必须保证一致性。要满足分布式事务，要么全部都成功，要么全部都不成功。
6.分布式事务解决方案：补偿机制TCC。XA。消息队列MQ。
事务补偿机制: 在事务链中的任何一个正向事务操作, 都必须存在一个完全符合回滚规则的可逆事务.
7.幂等性: 简单的说, 业务操作支持重试, 多次发起操作，不会产生不利影响. 常见的实现方式: 为消息额外增加唯一ID.
参考资料：
http://www.cnblogs.com/xingzc/p/5745587.html
https://cloud.tencent.com/developer/article/1117449
高并发高可用
1.海量数据的解决方案：
使用缓存； 页面静态化技术；数据库优化；分离数据库中活跃的数据；批量读取和延迟修改；读写分离；使用NoSQL和Hadoop等技术；分布式部署数据库；应用服务和数据服务分离；使用搜索引擎搜索数据库中的数据；进行业务的拆分；
2.高并发情况下的解决方案：
应用程序和静态资源文件进行分离；页面缓存；集群与分布式；反向代理；CDN；
3.高并发场景下的限流策略： 信号量;计数器(限制请求数量);滑动窗口;漏桶算法;令牌桶算法;分布式限流。
参考资料： https://cloud.tencent.com/developer/article/1181346
负载均衡
1.负载均衡：将流量或者请求均衡地分派到各个服务器。避免某个服务器压力过大。
2.负载均衡分为硬件负载均衡和软件负载均衡。
硬件负载均衡：主要通过在服务器节点之间安装专门用于负载均衡的设备，比如F5。
软件负载均衡：在服务器上安装一些具有均衡负载功能或模块的软件来完成请求分发工作。
3.负载均衡策略：
参考资料：https://juejin.im/post/5bbb5bd96fb9a05cf371478a
Nginx
1.负载均衡。
2.反向代理？到底是什么？
反向代理方式，是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器；
思考 ：正向代理是通过代理服务器去发起请求，比如我们日常说的"fang墙"。。反向代理则是通过代理服务器去接受请求。
Nginx就支持反向代理。
3.CDN是什么？
CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。CDN可以加速。
应用：玩某些游戏的时候，经常需要开加速器。就是基于CDN。
4.动静分离
分布式服务
1.RPC：远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。用Socket比较麻烦。
对于大多数rpc框架通用，实现的几个技术点：
- 服务提供者发布服务：服务接口定义，数据结构，服务提供者信息等；
- 客户端远程调用：通常是使用jdk的代码代理拦截；
- 底层通信：现在应该更多是使用netty吧，当然也有走支持http的；
- 序列化：关注序列化反序列性能，xml，json，hessiaon，pb，protostuff，kryo等；
常用的rpc框架： dubbo、Thrift、Hadoop的Avro-RPC、Hessian、gRPC
2.Soa ： 面向服务的架构。SOA 是一种软件架构模式，用于构建大型的企业应用程序，这些应用程序通常要求集成多种服务，而每种服务使用不同的平台和编程语言来构建，并通过通用的通信机制进行交互。
分布式锁
1.zookeeper，可以进行分布式服务协调，做为dubbo的服务注册中心。zookeeper还可以做分布式锁，也可以帮kafka存储元数据( topic，partition信息等）更新。
2.分布式系统的不同节点上需要分布式锁，那么我们需要了解分布式锁到底应该有哪些特点:
-
互斥性:和我们本地锁一样互斥性是最基本，但是分布式锁需要保证在不同节点的不同线程的互斥。
-
可重入性:同一个节点上的同一个线程如果获取了锁之后那么也可以再次获取这个锁。
-
锁超时:和本地锁一样支持锁超时，防止死锁。
-
高效，高可用:加锁和解锁需要高效，同时也需要保证高可用防止分布式锁失效，可以增加降级。
-
支持阻塞和非阻塞:和ReentrantLock一样支持lock和trylock以及tryLock(long timeOut)。
-
支持公平锁和非公平锁(可选):公平锁的意思是按照请求加锁的顺序获得锁，非公平锁就相反是无序的。这个一般来说实现的比较少。
常见的分布式锁有：zookeeper
分布式消息队列
1.消息队列，属于生产者-消费者模式。
消息队列做为中间件模式的的优点：解耦、异步、削峰。
削峰：系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。
常用的MQ有ActiveMQ,RabbitMQ,RocketMQ,Kafka。
2.kafka，可以做为消息队列。优点是分布式队列，吞吐量高。
搜索引擎
1.elasticsearch 是一个实时分布式搜索和分析引擎，可以应用在任何实时检索的场景中。
分布式session
1.首先是为什么会有这样的概念出现？
先考虑这样一个问题，现在我的应用需要部署在3台机器上。是不是出现这样一种情况，我第一次登陆，请求去了机器1，然后再机器1上创建了一个session；但是我第二次访问时，请求被路由到机器2了，但是机器2上并没有我的session信息，所以得重新登录。当然这种可以通过nginx的IP HASH负载策略来解决。对于同一个IP请求都会去同一个机器。
但是业务发展的越来越大，拆分的越来越多，机器数不断增加；很显然那种方案就不行了。那么这个时候就需要考虑是不是应该将session信息放在一个独立的机器上，所以分布式session要解决的问题其实就是分布式环境下的session共享的问题。
分布式数据库
1.假设有千万级/亿级的海量数据，如何设计数据库？
其他概念
1.Web Services ：可以将应用程序转换为网络应用程序
2.分布式系统怎么将任务分发到这些计算机节点呢，很简单的思想，分而治之，即分片（partition）。对于计算，那么就是对计算任务进行切换，每个节点算一些，最终汇总就行了，这就是MapReduce的思想
知识图谱：
参考资料：
