关于Mongodb的事务

关于事务：

     事务的隔离级别：未提交读(脏读数据)  已提交读  不可重复读  幻读（串行化 Serializable解决）

     uncommitted - read 解决：

     unrepeat - read 解决： 

 

MongoDB的部署方式：

单机模式：

    一个Primary：（在内存中）

             包含：一个DataBuffer    一个JournalBuffer

  步骤： 磁盘中有对应的DataFile   JournalFile 

     用户发送请求给Primary，先将数据日志缓冲到JournalBuffer，再将数据缓冲到DataBuffer 然后将数据返回给用户

     之后JournalBuffer 数据刷盘到 JournalFile （刷新频率较高 约100ms一次）最后DataBuffer数据刷盘到DataFile(大概60s一次)

高可用复制集：

     一个Primary  一个Secondary  多个Secondary

    Primary中包括：

           DataBuffer  JournalBuffer  Oplog  其他操作和单机模式一样

    复制集的优点：

     复制集在完成主从复制的基础上，通过心跳机制，一旦primary节点出现宕机，则触发选举一个新的主节点，剩下的secondary节点指向新的primary

           不同的是在数据缓冲到DataBuffer之后 会将 缓冲操作日志缓冲到Oplog中 然后在数据返回给用户之后，Oplog中的日志缓冲记录会同步到Secondary中 （频率最快 大概1ms一次）

可扩展分片集群：

 

有关WriteConcern：

     w = 0 / 1 / 2 / majority；

     j  =  1；

w = 0的时候性能最好 但是最不安全  会出现网络丢包 无效数据都不提醒 属于 UnAcknowledged

w = 1的时候属于 Acknowledged 是默认的状态

w = majority 属于推荐的状态

j = 1 时候安全性最高 但是性能损耗也是最大

 

可能会碰到的问题：

    journalData还没数据刷盘到JournalFile时候宕机 会导致数据丢失 使用 j = 1可以解决 

解决方式是：保证日志落盘后返回确定信息

    Oplog缓冲日志的时候系统宕机：

这个时候需要保证日志同步到一个节点才返回确认信息给客户端 需要使用w = 2 / majority / j = 1