大并发系统架构设计常用思路终稿.docxVIP

大并发系统设计常用思路1动静分离1.1程序分离：把静态资源与动态资源分开， SSI,SGI,CSI1.2部署分离：比如：js,html，图片，部署在web服务器，采用apache服务。动态业务逻辑使用tomcat服务1.3CDN使用第三方CDN或自建CDN，解决流量增长带来的带宽问题，同时可提升不同运营商访问速度，基本解决大流量的问题。2应用集群2.1主备方案使用双机主备，增加服务可用性。2.2应用集群2.2.1负载分层概念所谓四层就是基于IP+端口的负载均衡；七层就是基于URL等应用层信息的负载均衡；同理，还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 换句换说，二层负载均衡会通过一个虚拟MAC地址接收请求，然后再分配到真实的MAC地址；三层负载均衡会通过一个虚拟IP地址接收请求，然后再分配到真实的IP地址；四层通过虚拟IP+端口接收请求，然后再分配到真实的服务器；七层通过虚拟的URL或主机名接收请求，然后再分配到真实的服务器。2.2.2 nginx集群适应场景：优点：缺点：2.2.3lvs集群适应场景：优点：缺点：2.2.4F5集群适应场景：优点：缺点：2.2.5 HA-proxy适应场景：优点：缺点：2.2.6 终极负载架构演进推荐Nginxnginx+keepalivenginx+keepalive+f5(array)F5做负载，DNS轮询，Keepalive做浮点nginx主备，apache做静态服务，tomcat做SERVICE，Mysql做读写分离+集群（集群直接可替代读DB），redis做缓存集群+持久化。apacheMQ做异步服务通信。F5: F5 BIG-IP，Radware、Array、A10、Cisco、深信服和华夏创新都是负载均衡的牌子.硬件负载均衡，在芯片级完成，降低服务器性能开销。LVS:工作在网络4层上，使用linux内核集群实现，仅做分发，无流量产生，对内存与CPU消耗低。对网络稳定性依赖较大，安装配置性低，可配置内容较少，能对所有应用做负载需要耗费较多机器？？DNS轮询：NGINX: 工作在7层网络之上，对网络依赖小，能ping通就可以负载，配置简单，负载并发量几W次，相对较小。不保持SESSION，只能IP-HASH，不能通过URL检测服务器，只能通过端口检测，只支持http;https/email接口。正则表达规则较强。3缓存方案3.1 redis3.2 memcached3.3 缓存垂直分离3.4 缓存集群3.5 缓存持久化3.6事务缓存写缓存有事务存在时的回退问题，与DB不一致问题，使用持久化日志定期对比更新方案缓存重启：从DB重新读取数据，缓存中已在持久化中的数据需要先同步到DB缓存主备与集群问题缓存水平分离问题4数据库优化（mysql）4.1 读写分离数据库配置：Masterslave,通常认为读写请求比例为10：1，一主多从程序设计：mysql读写分离代理，连接池指定数据源路由缺点：写压力较大时，无法进一步提升并发量Master写压力占用cpu与内存达到100%左右，slave存在较长的延时，实时性很难保证。读写分离程序设计：设置两个数据源，在程序中根据读写业务属性指定数据源类型，读数据源配置为slave，写数据源配置为master。事务型业务逻辑需要指定数据源以保证数据完整性。这样即使出现读写数据库延时情况，事务本身不会出现异常。读数据库有多个slave情况下，增加路由策略层，配置多个slave，并在创建连接时，根据不同策略（循环、IPhash，权重、模块）指向不同slave数据库。根据sql语句读写情况，自动分配读OR写数据源。同一事务中即有读又有写操作时，容易因延时引起数据事务异常。mysql ReplicationDriver，mysql驱动，定义了1，2，3步骤中步骤。通过readonly属性进行区分读写数据库。Mysql-proxy :稳定性较差Amoeba for MySQL：阿里开源中间件，实现读写分离权重配置。4.2集群优点：DB级配置完成，程序基本无须修改缺点：数据库复制存在延时，双向读写产生更复杂的性能问题，效果有限4.3 垂直分离4.3.1垂直拆分方法sharding化数据驱动开发使用E-R图或业务驱动开发使用领域模型，倾向于使用领域模型。业务紧密关联的表放一个shard，使用活动图泳道的概念。一个泳道一个shard.数据增量大，进行水平切分将每个shard划分为子shard，子shard只有一个主表（以该表ID进行散列）与多个与其关联的次表，产生大量shard，然后将shard按相近的数据增长速度进行合并，多个shard可放在同一DB上，同一DB上合并的shard散列取模（节点数）一致，但逻辑独立。跨shard的间关联打断，join，g