学习笔记之 高并发处理系统的理解

服务器配置：

         集群的环境，每个主机选择apahe 还是nginx，nignx的并发性好。nginx和apche区别 以及服务器的配置，例如缓存大小等

        根据实际情况，可能对于图像比较多的情况，单独配置nginx服务器，作为图像服务器。在实习中使用的是七牛家的云存储单独作为图片存储，将有关车辆的上传图片全部放在上面。

 

数据库设计以及优化

       （1）表的设计：

           存储引擎：innodb还是 myisam？ innodb支持事务外键，可以在崩溃时恢复（事务中redo日志实现），myisam不支持；存放数据的方式不同:myisam将表的结构frm 数据myd索引myi存在数据库目标中；innodb只在数据库目标文件中存在表的结构；索引采用B+树，myisam索引叶结点保存的是指针，指向数据，innodb存的就是数据；myisam占用空间小，在读的业务比较多的情况下采用myisam比较好。

         字段的设置： 尽量使用短的字段，提高效率，建立索引也能减少资源浪费； 整型类型，比字符类型比较快；varchar 和 char不定长（节约空间）和定长（查询快）选用；索引字段：该字段进行不同的比较多，字段值不易过长。

         合理选择数据的冗余：可以根据实际情况，不满足三范式：设置冗余字段，可以减少客户的处理，满足三范式，表之间的关系比较清晰，但是因为有外键什么的，多表关联可能性能降低，加大了用户的编程难度。

        索引优化

      （2）分库分表

        针对大表，可以根据实际情况垂直分表或者水平分表。

      垂直分表：对于大表中的某些字段经常使用，可以分表；

      水平分表：例如月份，将不同的月份的数据存在不同的表中。

    （3）MySQL集群的环境

       读写分离：主要针对读操作比较多的情况下。

 

        目的:给大型网站缓解查询压力

        原理：服务器运行amobe服务，可以判断sql是写还是读操作。收到sql语句是写，服务器将写送到master mysql处理，利用mysql proxy机制然后同步到slave mysql；

         当服务器是select时，服务器会根据负载均衡挑选出一个slave mysql，将select语句送到并处理。

缓存：

       可以将一些不动的页面：页面静态化/部分页面静态化；

        或者将一些数据存在memcache或者Redis中，不用去查表

 

数据一致性处理

      当多个进程同时操作同一个数据，会产生资源争抢，数据一致性的问题。

       高并发情况下，涉及到写操作时，不可能直接操作数据库，大并发的连接会导致mysql请求会阻塞，比如大量的insert update 请求到，会直接导致无数的行锁和表锁，甚至最后堆积很多，从来触发too many connections 错误。

     web服务器 nginx和apache连接的进程有限，cpu上下文进程切换也会增加额外的开销，所以响应一定快。

      这时可以采用

     高并发下的数据安全，防超发，以抢票系统为例：

    （1）消息队列：

        将票数资源存在redis中，将请求存入消息队列（redis下的list阻塞的，可以实现消息队列，还可以实现优先消息队列点击打开链接）中，依次处理。缺点 ：这样会处理比较慢，等待时间比较长。

    

：对于读操作是否也进入队列，这个问题根据具体的场景，像12306应该是不在队列中或者是优先排在最前面的，因为只是读，要求块。 

（2）加锁

      常见的锁：        排它锁；乐观锁；悲观锁；

      排他锁：在进行写时，禁止一切的读和写；

      乐观锁：认为在写的时候，别人不在写，维护一个version号，等处理后对照version好，一致则对，否则回滚，操作不成功，

      悲观锁：认为在写的时候，别人也在写。采用数据库提供的锁机制：在写操作的时（insert updata 等）myisam默认是锁表，innodb根据是否是主键，主键则行锁，否则表锁。读操作，innodb采用mvcc版本控制。

     可以采用乐观锁+回滚：

       

    采用悲观锁：

    

一个项目刚开始的时候是为了实现基本功能，随着版本和功能的迭代，大数据和高并发成了软件设计必须考虑的问题!

本质很简单，一个是慢，一个是等。

两者是相互关联的，因为慢，所以要等，因为等，所以慢，解决了慢，也就解决了等，解决了等，也就解决了慢。

关键是如何解决慢和等，核心一个是短，一个是少，一个是分流,最后一个是集群/横向扩张/读写分离/建立主从。

 

 

• 短是指路径要短:

 

典型的mvc结构是请求->controller->model->dao->view，然后把页面返回给用户。要想短的话，

1，页面静态化- 用户可以直接获取页面，不用走那么多流程，比较适用于页面不频繁更新。

2，使用缓存- 第一次获取数据从数据库准提取，然后保存在缓存中，以后就可以直接从缓存提取数据。不过需要有机制维持缓存和数据库的一致性。

3，使用储存过程-那些处理一次请求需要多次访问数据库的操作，可以把操作整合到储存过程，这样只要一次数据库访问就可以了。

4，批量读取 - 高并发情况下，可以把多个请求的查询合并到一次进行，以减少数据库的访问次数

5，延迟修改 - 高并发情况下，可以把多次修改请求，先保存在缓存中，然后定时将缓存中的数据保存到数据库中，风险是可能会断电丢失缓存中的数据，

6,  使用索引 - 索引可以看作是特殊的缓存，尽量使用索引就要求where字句中精确的给出索引列的值。

 

 

• 少是指查询的数据要少:

 

1，分表 - 把本来同一张表的内容，可以按照地区，类别等分成多张表，很简单的一个思路，但是要尽量避免分出来的多表关联查询。

2，分离活跃数据 - 例如登录用户业务，注册用户很多，但是活跃的登录用户很少，可以把活跃用户专门保存一张表，查询是先查询活跃表，没有的话再查总表，这也类似与缓存啦。

3， 分块 - 数据库层面的优化，对程序是透明的，查询大数据只用找到相应块就行。

 

 

• 分流三种:

 

1，集群 - 将并发请求分配到不同的服务器上，可以是业务服务器，也可以是数据库服务器。

2，分布式 - 分布式是把单次请求的多项业务逻辑分配到多个服务器上，这样可以同步处理很多逻辑，一般使用与特别复杂的业务请求。

3，CDN - 在域名解析层面的分流，例如将华南地区的用户请求分配到华南的服务器，华中地区的用户请求分配到华中的服务器。