系统分析原则

1.高并发原则

垂直扩展:通过增加软件技术或升级硬件来提高单机性能。
水平扩展:通过增加服务器的节点个数来横向扩展系统的性能。
    具体来讲，在技术层面，可以使用缓存减少对数据库的访问，用熔断或降级提高响应的速度，通过流量削峰等手段在项目等入口限流，先拆分项目或使用微服务技术快速构建功能模块，然后在用SpringCloud或dubbo等统一治理这些模块，通过中间件搭建基于读写分离的高可用数据库集群等。在系统测试阶段，还可以使用]Profler等工具进行性能分析，寻找性能瓶颈，从而有针对性的去优化。

衡量高并发的常见指标包括:
    1.响应时间:系统对请求作出响应的时间。例如: 系统处理一个http请求需要200ms，这个200ms就是系统的响应时间.
    2.吞吐量或QPS(Query per Second，每秒查询率):单位时间内处理的请求数量
    3.并发用户数:同时承载正常使用系统功能的用户数量，例如:一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数

2.容错原则

3.CAP原则

    一致性、可用性、分区容错性

4.幂等性原则

    幂等概念来自数学，表示N次变换和1次变换的结果是相同的。这里讨论在某些场景下，客户端在调用服务没有达到预期结果时，会进行多次调用，为避免多次重复的调用对服务资源产生副作用，服务提供者会承诺满足幂等。HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的副作用（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
        幂等不仅仅只是一次（或多次）请求对资源没有副作用（比如查询数据库操作，没有增删改，因此没有对数据库有任何影    响）。
        幂等还包括第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。
        幂等关注的是以后的多次请求是否对资源产生的副作用，而不关注结果。
        网络超时等问题，不是幂等的讨论范围。
    幂等性是系统服务对外一种承诺（而不是实现），承诺只要调用接口成功，外部多次调用对系统的影响是一致的。声明为幂等的服务会认为外部调用失败是常态，并且失败之后必然会有重试。

5.可扩展原则

6.可维护原则与可监控原则

    1)项目的日志记录功能完善，易于追溯问题、统计操作等
    2)有BugFree等bug管理工具
    3)有丰富的项目文档和注释
    4)统一的开发规范，比如讲:变量的命名、少用缩写、代码缩进、面向接口编程、编码和配置分离、适当采用设计模式等
    5)模块画的编程方式

处理高并发问题的常见方法有如下几种

1..缓存方面

    将一些有时效性或经常访问的数据存储在专门用于缓存的应用程序中，减少数据库的访问压力，常见的缓存技术:
    本地缓存: cache
    分布式缓存: redis

2.数据库方面 

    优化数据库查询语句，复杂的SOL语句不要使用orm 框架自动生成而非手动编写，同时优化数据库的表结构，如加入索引等。数据库读写分离，主数据服务器负责写，从数据库服务器负责读，通过主从复置的原则来保证数据的完整性
    1)对表分区
    2)对数据库服务器的硬件进行升级
    3)表的设计需要符合三方式
    4)添加适当的存储过程、事务等

3.负载均衡

    做服务集群部署，同时使用Nginx、Ribbon做负载均衡

4.流量削峰

    将处理消息放入MQ，顺序读取执行程序

5.动静分离

    将静态资源加入CDN中快速访问

6.降级和熔断

    关于降级的方法业界都已经有很成熟的方法了，比如Hystrix的fallback机制。当服务请求超时或错误时，走fallback方法。因此我们可以配置服务请求的超时时间。
    Hystrix的CircuitBreaker机制可以实现熔断。当调用满足失败次数，失败比例就会触发熔断器打开。熔断器打开了，后续请求直接走降级方法fallback，不再调用主流程方法。 可以设置参数：x个请求开始进行熔断错误比率计算、当出错率超过xx%后熔断器启动、熔断器工作时间超过某个时间先放一个请求进去成功的话就关闭熔断失败就再等一段时间。

7.异步调用

    根据业务场景分析，对于不需要请求同步执行的处理做异步处理