高并发大流量站点架构简单思路

******************************* 前端 ******************************* 1.添加必要的硬件和带宽，同一时候额外储备一部分，以备不时之需 2.特别监控网络数据流量是否正常。如是否有大规模的爬虫、DDOS等浑水摸鱼，可以针对iP和Cookie的限流 3.使用CDN同一时候作一些必要的算法改造，动静分离 ******************************* 代码端 ******************************* 1.必要的代码优化改造如软件升级、慢查询、client缓存、多线程之类 2.设计高峰期时的降级使用：关掉或暂停非核心的页面功能、后端统计功能 3.SOA作好横向扩展，最好是本身主动化扩展 4.负载选择七层仍是四层。负载会不是瓶颈 5.各类高大上的缓存：reids、mongdb、memcache等 6.web到数据库端需要一个“隔离区”，让数据平稳、源源不断的进入数据库 7.尽可能不要使用带复杂业务逻辑处理的存储过程（犹其是在N大数据结果集中作业务逻辑处理)。下降数据库CPU和内存压力 8.功能模块间。作好隔离。不能因为一个功能载入不出数据。而影响其余非相互依赖功能。 9.合理的链接池设计 ******************************* 后端 ******************************* 1.主从复制： 状况1：很是难作到实时，但是切换时，可能有部分数据没有同步过来，带来了数据的一致性问题。 可以在操做主数据库的同一时候。记录操做日志。切换到备时，会和操做日志作个check，补齐未同步过来的数据。 状况2：dbrd+master-slave模式或share eveything架构 2.PXC或MGC群集的share nothing架构 3.依照页面不一样需求拆分数据库:如用户登陆、购物车、下单、支付等分布在不一样数据库 4.按区域划分DB：如华东、华北、华中、华南、华西不一样区域用户到不一样IDC的DB，最后数据汇总到总部IDC就能够；当问题爆发时不会影响全局。单机房DB压力会减小. 5.数据库硬件：如使用SSD、闪存存储等. 6.纯内存数据库：如timesten、HANA或本身定制开发 7.杀手锏： 1）强行设置交易完毕如起飞时间也过也不可能退款的数据归档。归档数据仅仅供查询 . 2）假设第一种强行归档数据量依旧巨大，可以依照天如10天以前的归档。毕竟 80以上的交易都会完毕。在不大量改动代码的状况，如前端需要退款、改签处理， 将数据直接insert导入主库就能够，毕竟数据库insert不是最大的瓶颈. 3）依照订单状态拆分：下单未支付、支付完毕、处理中、支付完毕。分别架构到不一样的表. ---------多机房容灾探讨 1.异地机房容灾 A->P仍是A->A 2.单机房可以考虑多路光纤 3.底层复制：硬件、软件(RSYNC、DBRD、OGG)