问：内部的存储结构？
答：Bson
问：怎么实现事务的
答：MongoDB3.0支持单文档事务，基于WiredTiger引擎，保证数据，索引，oplog三者的原子性
问：MongoDB实现事务的难点在于时序问题
答：MongoDB 通过 oplog 时间戳来标识全局顺序，而 WiredTiger 通过内部的事务ID来标识全局顺序，在实现上，2者没有任何关联。这就导致在并发情况下， MongoDB 看到的事务提交顺序与 WiredTiger 看到的事务提交顺序不一致。这种情况下，MongoDB4.0中WiredTiger只能做调整，加入时间戳transaction timestamp；
在 3.x 版本里，一个写请求对数据、索引、oplog的修改会放到一个 WT 事务里，事务的提交由 MongoDB 自己控制，MongoDB 会尽可能快的提交事务，完成写清求；但 4.0 引入事务之后，事务的提交由应用程序控制，可能出现一个事务修改很多，并且很长时间不提交，这会给 WT cache evict 造成很大的影响，如果大量内存无法 evict，最终就会进入 cache stuck 状态。为了尽量减小 WT cache 压力，MongoDB 4.0 事务功能有一些限制，但事务资源占用超过一定阈值时，会自动 abort 来释放资源。
问：一个事务中文档数可以非常大吗？一个事务操作最大允许时间是多大？
答：（1）事务的生命周期不能超过 transactionLifetimeLimitSeconds （默认60s），该配置可在线修改，（2）事务修改的文档数不能超过 1000 ，不可修改
问：事务如何回滚？
答：在 3.x 版本里，MongoDB 的节点需要回滚时，会根据要回滚的 oplog 不断应用相反的操作，或从回滚源上读取最新的版本，整个回滚操作效率很低。
4.0 版本实现了存储引擎层的回滚机制，当复制集节点需要回滚时，直接调用 WiredTiger 接口，将数据回滚到某个稳定版本（实际上就是一个 Checkpoint），这个稳定版本则依赖于 stable timestamp。WiredTiger 会确保 stable timestamp 之后的数据不会写到 Checkpoint里。
问：MongoDB持久化策略？
答：在MongoDB启动的时候，会开启一个线程去循环将数据写入磁盘，但是写的方式是有一定时间周期，异步延迟去写