系统优化分析:
1.view层的优化，具体是指web前端优化：
a.前端代码的优化（业务方向的优化，架构设计方向的优化，具体代码逻辑方向的优化），前端的缓存的使用。
2.请求层的优化，具体是指nginx等请求代理服务器：
a.反向代理，b.动静分离。
3.后端层面的优化：
(1)如果某个接口请求的数据是多个查询拼成的结果的话，可以把每个查询看成一个线程，然后将最后的结果拼好返回给前端。
(2) rpc调用负载均衡。
(3)在java中，vector，hashtable,concurrentHashMap是线程安全的，其实也是他们都是加了对象锁，如果我们开发中，使用了hashMap，但是也想它是线程安全的，
我们可以在它使用hashmap这个方法当中进行锁，也是可以实现线城安全的，但是这样的锁的东西就多一下，锁的粒度就大一些，影响性能。所以一般要求锁的粒度越小越好。
即保证线程安全的情况下，锁的粒度越小，锁持有的时间越短，系统性能越高。
4.数据库层的优化：
a.数据库集群，
b.主从复制，读写分离
c.关系型数据库和非关系型数据库相结合
d.分库分表
e.数据查询慢，一般由于数据量大，又要做统计分析等等，这样可以设计粒度更大的数据库来存储多维度统计来的数据(知学云就是这样弄的，监听binlog数据，然后累计到相应维度的表中)，
大数据貌似也是这种思想。
f.数据库的查询优化：
查询优化的常用策略
一般常用的查询优化策略有优化数据访问、重写SQL、重新设计表、添加索引4种。下面将分别介绍这4种优化策略。
（1）优化数据访问
应该尽量减少对数据的访问。一般有如下两个需要考虑的地方：应用程序应减少对数据库的数据访问，数据库应减少实际
扫描的记录数。
例如，如果应用程序可以缓存数据，就可以不需要从数据库中直接读取数据。
例如，如果应用程序只需要几个列的数据，就没有必要把所有列的数据全部读取出来，应该尽可能地避免“SELECT*FROM
table_name”这样的语句。
例如，有时我们在慢查询日志里会看到Rows_examined这一项的值很高，而实际上，并不需要扫描大量的数据，这种情况下
添加索引或增加筛选条件都可以极大地减少记录扫描的行数。
例如：表关联比较多的查询，可以采用多步查询，然后拼接在一起，显示在前端。
类似的例子还有很多，这里就不一一列举了。
（2）重写SQL
由于复杂查询严重降低了并发性，因此为了让程序更适于扩展，我们可以把复杂的查询分解为多个简单的查询。一般来说
多个简单查询的总成本是小于一个复杂查询的。
对于需要进行大量数据的操作，可以分批执行，以减少对生产系统产生的影响，从而缓解复制超时。
由于MySQL连接（JOIN）严重降低了并发性，对于高并发，高性能的服务，应该尽量避免连接太多表，如果可能，对于
一些严重影响性能的SQL，建议程序在应用层就实现部分连接的功能。这样的好处是：可以更方便、更高效地缓存数据，方便
迁移表到另外的机器，扩展性也更好。
（3）重新设计库表
有些情况下，我们即使是重写SQL或添加索引也是解决不了问题的，这个时候可能要考虑更改表结构的设计。比如，可以
增加一个缓存表，暂存统计数据，或者可以增加冗余列，以减少连接。优化的主要方向是进行反范式设计，反范式的设计请参
考4.1节。
（4）添加索引
生产环境中的性能问题，可能80%的都是索引的问题，所以优化好索引，就已经有了一个好的开始。
（5）慎用临时表。
(6) 查询sql语句和count统计sql语句可以分开写，如果某个表的中所以有字段都没有作为查询条件来筛选，只是作为显示的话，可以不用关联该表来count统计。
(7) 如果数据库的日期字段存放的是毫秒类型的字段，也做了相应的索引，那么筛选的时候不要使用聚合函数对字段进行处理,这样索引会失效的。
（8）表与表之间关联查询时，尽量是小表驱动大表（sql语句的逻辑层的优化）