大型系统并发处理与架构设计
在我们搭建大型系统（用户量）的时候并发是一个很头疼的问题，如何设计好这个系统是一个很重要的问题。
1.瞬时并发
在平常并发量并不是很多，但是当比如搞活动的时候并发量突然猛增，这时候处理方式。
这个时候我们需要将所有的请求拦截下来（拦截器或其他方式），把请求信息放到我们设定好的消息队列中，然后由消息队列来控制给服务器灌入，避免同时大量请求直接进入服务器，使服务器挂掉。
但是这样如果我们的消息队列满了的话，那应该怎么办呢？
消息队列满了，但是我们的请求不能丢掉，这时候我们需要额外的加一层消息队列的保障，保障当消息队列满的时候，请求不丢失。
2.持续并发
即使在平常的日子并发量也很高，这个时候一台服务器已经满足不了要求，需要搭建服务器集群。
说一下概念的问题：
集群：指多个服务器做相同的事情；
分布式：指多个服务器做不同的步骤。
那这个时候我们的处理方案：
这个时候所有的请求全部交给nginx来分配给不同的服务器。
nginx通过配置计算机ip和域名来分配，也可以分配权重。
但是这个时候我们来模拟一个登录的功能（token或session）
第一登录的时候，nginx分配到了第一台服务器上，登录信息也存在了第一台服务器上。那么第二次请求，把我的请求分配到了第二个服务上，第二个服务器上没有我的登录信息，提示我登录。这个时候就出现了问题，那我们怎么解决这个问题呢？
那我可以通过配置使同一个ip的请求都分配到同一个服务器上来解决。
但是问题又来了，如果你使用的服务器宕机了怎么办（使用的时候不只你一个人，很多人都在使用，不能影响用户的使用）？
这个时候呢，需要额外的配置一个东西来存储用户的登录信息（常用redis），这个时候不管分配到了哪个服务器上，都通过访问redis中的数据来进行验证。
那这样是不是就好了呢？不是的，还存在比如redis挂了怎么办？
像数据库（sql,nosql）这样存数据的东西，一旦挂了如果没有预防方案，损失很大。通常采用主从同步的方式来预防这个问题。
当然像单个数据库已经扛不住的情况，都可以采用集群的方式来解决，采用数据库集群。
3.架构设计
先看一张架构图
1.前台网页资源与后台分离。
2.取消service模式，采用微服务方式，减少代码的重用。
外话：微服务的由来：加入我要开发两个系统，在我开发第二个系统的时候，发现有90%的功能在第一个系统上开发过，这时候我就不回去重复开发，而会把原来的功能抽出来，整成接口，谁用调用接口就好。
4.rpc
因为越来越多的微服务产生，很容出现一个问题。
比如：A开发了一套系统，有a功能，抽成了接口。B开发另外一套系统也用到了a功能，没有跟A说，直接接到了a接口，这时候
C开发了一套系统也用到了a功能，也直接掉用a接口，看起来很方便。但是当B开发的系统开始搞活动，导致并发量猛增。直接把a功能的服务器挂掉了。直接导致A系统也崩了。这时候老板来找原因，谁也不说。最后A悲惨的背锅。
RPC是一个提供微服务管理框架的远程过程调用协议，他可以更好的管理微服务。
rpc中生产者是提供接口的一方，需要在管理平台上进行注册，注册以后平台会记录这个服务的配置信息（ip等），然后返回给服务，下次再调用的时候直接比对token就好。
然后平台要对服务的服务器进行心跳监控，防止服务器宕机，其他应用还在使用该服务器。
调用者需要再平台进行注册，记录信息。同样返回一个token，调用者请求使用接口，平台根据接口的并发量的决定是否同意调用。同意之后，调用者开始使用创造者的接口，但是每隔一定时间，调用者获取轮询一下服务器的信息，为了防止添加服务器，而调用者不知道的情况。