今天早起把架构的第四章学完了。保证存储数据的高可用。
关系型数据库是因为完整的事务的特性，为大多数企业采用。当达到海量数据的时候只能考虑集群方式去优化了。而真正面对海量数据的优化方案主要有"读写分离"和"分库分表"。
读写分离是把读库和写库分开，写库会实时同步数据到读库，可能存在的问题就是同步延迟，不能实时看到写入的数据。
业务分库是指给每一项核心业务专门设置数据库，分开存储。这样做会增加很多技术挑战，很多sql查询语句都失效了。join联查语句部分要整改，其次是每个数据库都只能处理自己的事务，要考虑分布式事务解决方案，再者就是服务器的数量和成本增加了。
每增加一种技术延伸，原有的很多东西都要跟着改变，架构越复杂，变化越大。所以初创公司不建议一开始设计就弄分库分表，一个项目的成功概率和失败概率一样大，有的项目可能几年也累积不到一万个用户，弄亿级的数据库没有意义，单机就行了，连集群都不需要考虑。
分表可分为垂直拆分和水平拆分两个纬度，垂直拆分没有技术含量，就相当于把蛋糕竖着切，而水平拆分可以根据多种算法和规则拆分，可以类比为把一个excel的一个sheet页的上亿数据按照某种规则拆分到多个不同sheet里面，等要查询数据的时候需要同时从那些拆分好的sheet里面查数据。常用的规则有范围路由(根据某列有序的值的范围)、hash路由(根据hash值)、配置路由(根据自定义配置表)。
水平拆分之后，很多sql语句功能也要变化才能有效，比如join操作、count()操作、order by 排序操作。
上面是关系型数据库的存储，对于非关系型，也就是Nosql,全称是not only sql.不仅仅是sql,它是对关系型存储的一种补充。
世间万物是互补的，没有一个完美的终极方案，只有特定领域的优势互补。火车没有替代汽车，飞机也没有替代火车。
关系型数据库的最大特点是强约束验证，它要进行大量的验证保证数据的完整性和一致性，这样会牺牲大量的性能，在千万的级别它勉强适合用于检索……会往上会有瓶颈，其次它的设计决定了它不适合做全文检索，全文检索可以用一个成语类比"大海捞针"。还有，关系型数据库是按每列每个字段存储，所以它不能直接存储类似于set、list之类的数据结构。我们不能设计一个万能的存储技术。
nosql的方案有4种，而且几乎被互联网企业大量使用:
1.键_值存储:课代表叫redis,微信和微博都是用它。
2.文档数据库:课代表为MONGODB.
3.列式数据库:课代表为Hbase,它本质是也是大数据的解决方案框架。
4.全文检索引擎:课代表是Elasticsearch, 我最近也在学习它。
Redis我接触最多，它除了可以做缓存使用之外还有很多妙用，比如做商场的秒杀活动，秒杀本质是几秒钟内几万次请求，如果是访问关系型数据库的话，数据库肯定承受不了，而redis的数据是在内存中的，直接访问内存是没有问题的，不需要考虑事务，只需要考虑是否卖超了，这就是秒杀最关注的点。它还可以做分布式系统的session共享和分布式锁。微博最常用的操作就是把热点数据和明星发的微博都存到缓存中，这样都是为了提高系统性能和保全关系型数据库的访问压力问题。
每种方案都有各自的特点，只有某个业务场景符合某种技术的时候才要考虑到它，比如列式数据库只有对于针对某列的统计的时候才会发挥巨大作用，因为平常关系型数据库会把一行信息都查出来，太浪费性能了。又比如我们去欧洲旅行，首选的交通工具是飞机，但假如你的需求是拍沿途风景，那么几天几夜的火车也是可以考虑的。
缓存还会有一些常用问题
缓存穿透
比如某些数据在数据库里和缓存里都没有，那么每次都还是需要去数据库查询，当有些黑客刻意用这个查询去攻击的时候，可能会让你的应用服务器崩溃。常用的解决办法是如果没有对应值，也要在缓存生成一个键值对，返回空内容，这样缓存就可以保护数据库了。
缓存雪崩
大量缓存失效或者缓存生成时间很长，都会造成大量请求直接绕过缓存去请求应用服务器，可能会让应用瘫痪，这点和地球非常类似，大气层就像缓存一样保护着地球，一些陨石就是请求……
解决雪崩的方案是可以对更新缓存加一把更新锁，确保每次只有一个请求更新缓存，其它请求会直接返回null ，另一种方案是采用后定时去更新缓存。