一、主要挑战
1、动态服务部署架构
用户请求—>DNS—>负载均衡（软件LVS/硬件F5）—>分发（长连接：Varnish/短连接：Nginx）—>应用功能（apache/tomcat）
2、挑战
高性能，高并发，高可用，可扩展，大数据
3、
传统web部署
web（local cache）—>MySql
现代
web（local cache）—>Memcached（加速层）—>MySql
采用多个MC实例，分摊整个库，每个实例存一部分。
不宜过多，因为内存价格贵，并且过多查找性能降低
4、MC实例分摊数据时的hash策略
原则：单调性，平衡性
单调性：节点（mc实例）个数变动对数据移动影响最小
平衡性：尽可能散列到所有空间
传统：取模的hash，单调性差
现代：一致性hash
5、一致性hash
a) 环形的hash空间 : 解决单调性问题。
如：有3个mc实例
则把一个环用三个点均分成三段空间，每个实例（点）就近分得一段环（数据段）。
这样增加节点，删除节点，数据影响仅为该店的相邻节点。
b）虚拟节点： 解决平衡性问题。
在点分环时，增加该点的虚拟节点（分身），放该点在环的对立方向或与该点等分环的地方。
这样，在节点分环空间时，即分得的是环上等距的几个（取决于分身个数）数据片段，而非之前的一大段连续的空间。而单调性并未受影响。
6、读写分离
读数据—>mc
写数据—>MySqL（master）—>同步MySqL（salve）<——MC读取
有主从延迟风险
7、分库分表
多个MySqL
二、常见问题&解决
1、主从延迟
写入方式：
a）read through： 上文读写分离的流程 有主从延迟风险
b）write back ：写master DB的同时，写MC
若MC用短缓存，数据写入失败时可以及时更新MC，缺点是失效快，给salveDB造成压力。
若MC用长缓存，情况相反
c）写标记：写master DB的同时，写标记给MC
若有标记读master DB，没有读MC
2、瞬间峰值
队列机制：MCQ/KafkaMQ
Feed服务架构：
前端机：服务策略检测—>写入时放队列—>队列处理机读队列—>写DB
相当于把一大堆数据，攒一小坨一起处理一下，攒一小坨一起处理一下。
三、趋势
这个世界变化快
硬件提升
软件提升：
1、redis：key-value存储系统
相比MC，它可持久化
并且可以原子操作。
2、HBase：分布式数据库
文中出现的软件：
redis，HBase，varnish，nginx，LVS，F5，memcached，MCQ，KafkaMQ
参考：
+++++++++++++++++++
结合新员工入职时的培训，基本上弄懂了做大型网站的构架，运维的力量。
之前看过构建高性能网站，还有日本人写的一本书，（死活想不起来名字了……）
现在也都忘得差不多了，真是不写笔记不行啊……