qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

NoSQL数据库:数据的一致性

读取一致性
  · 强一致性
  在任何时间访问集群中任一结点,得到的数据结果一致;
  · 用户一致性
  对同一用户,访问集群期间得到的数据一致;
  解决用户一致性:使用粘性会话,将会话绑定到特定结点来处理;
  这样会降低负载均衡器的性能;
  · 最终一致性
  集群中各结点间由于数据同步不及时造成暂时的数据不一致,但数据同步完成后,最终具有一致性;
  更新一致性
  · 悲观方式
  使用写锁
  大幅降低系统响应能力
  可能导致死锁
  · 乐观方式
  先让冲突发生,再检测顺序
  自动合并的处理方式极具“领域特定”问题
  放宽“一致性约束”
  · CAP定理
  一致性(Consistency)、可用性(Availability)和分区耐受性(Partition tolerance),3个属性只可能同时满足2个;
  分区耐受性的解释:集群因通信故障而划分为多个时仍然可用
  · CA系统
  单服务器
  集群中出现”分区“,就不可用
  · PA/PC
  集群出现”分区“时,需要在”一致性“ 和“可用性”间权衡
  一般会牺牲部分一致性(eg:使用最终一致性),保证可用性
 放宽“持久性”约束
  更严格的持久性,意味着更多的性能损失;
  · 牺牲“持久性”换取更好的性能
  · 复制“持久性”故障
  主节点故障,未同步到从节点的数据丢失
  主节点恢复,故障期间更新的数据冲突
  解决方案:针对单个请求指定其所需的持久性
  附思维导图

posted on 2014-07-07 20:45 顺其自然EVO 阅读(148) 评论(0)  编辑  收藏 所属分类: 数据库


只有注册用户登录后才能发表评论。


网站导航:
 
<2014年7月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜