标签：内存不足 bsp 抽取 eem 场景 业务 类型 优化 复杂
http://mp.weixin.qq.com/s?__biz=MzIyNjE4NjI2Nw==&mid=2652558728&idx=1&sn=867d9b0385b91cc144844df2c8871362&chksm=f39a30fcc4edb9ea4c7878953d147a3d5820c1e677b7a29ef791f1bcc98fe6d6ca7bd84e1ad6&mpshare=1&scene=23&srcid=05062RxK00c9NJISF2Sa97cu##
1.分库分表 解决数据问题
基于主从解决读写压力问题
数据 一住多从 延迟从。 防止数据误删。
右侧可用区A区：A区是现在主要的架构，为了缓解读写压力而采用了“一主四从”的模式。另一种“一主两从”的模式则主要用于线上业务，其中“一从”是供大数据分析部门做数据抽取使用， “另一从”则充当延时的节点，以防止数据被误删的情况。同时一些数据节点可以采用多台机器共用一个物理机方式以节约成本。
青睐MongoDB理由
七．事务问题
1.后台定时修正 2.队列 3.二阶段提交 这三种解决方案
，但从开发人员的对事务的理解以及对代码的维护性等角度来说过于复杂。因为有些事务和业务高度耦合，后两种方案往往不利于维护这些代码；而在后台定时修正这个方案中，它通过将所有代码都集中在这一块来简化修正这个过程，同时也允许选择性地修正对事务要求较高的那一部分，以尽量地避免事情发生。
八．事务问题中仍存在的不足之处
内存不足时
开启内存文件映射引擎
内存和数据一样差
--前一周升级一个机器
数据存储 2亿 查询吃力 sharing比较令人满意
片键
满足业务场景
避免负载不均匀
share-key chunk
集群瘫痪。
share-key
避免负载不均匀：分片有两种，一种基于hash的，另一种基于range
借助数组、字典等数据类型：
事物要求严格
和传统数据库 相互换换难
没有scheem
多看文档
运维自动化方面
基于rockmongo优化了权限控制
监控数据库和表的增长
大表加索引：不同于background这种做法， 当超过100万时我们会采用官方的滚动加索引的方式，只对在线用户需要用到的表加索引，并且白天时间是不加索引的。采用Background这种方式加索引固然有它的好处，它可以不影响业务，并且保持这台机器不下线
标签：内存不足 bsp 抽取 eem 场景 业务 类型 优化 复杂
原文地址：http://www.cnblogs.com/itxuexiwang/p/6816198.html
