《Windows Azure Platform 系列文章目录》
绝大部分的商业分布式数据库，要求开发人员选择两个极端的数据库一致性：强一致性(Strong Consistency)和最终一致性(Eventual Consistency)
在笔者之前的文章中，我们介绍了Azure CosmosDB的五种一致性级别:
- Strong (强一致性)
- Bounded Staleness
- Session (会话一致性)
- Consistent prefix (一致性前缀)
- 最终一致性 (Eventual Consistency)
五种一致性级别在可用性(availability)和性能(Performance)方面进行了权衡，并有全面的SLA保障。
以下简单的注意事项将有助于我们在常见方案中选择合适的一致性场景。
SQL API:
如果我们的应用程序使用CosmosDB SQL API生成的，请注意以下几点：
1.在大部分的使用场景中，Session (会话一致性)是最佳，也是推荐的选项
2.如果应用程序需要强一致性，建议使用Bounded Staleness级别
3.如果需要提供比Session (会话一致性)提供更严格的写入毫秒延迟保证，建议使用Bounded Staleness级别
4.如果应用程序需要最终一致性(Eventual Consistency)，建议使用Consistent prefix (一致性前缀)级别
5.如果需要的一致性级别不如Session (会话一致性)那么严格的话，建议使用Consistent prefix (一致性前缀)级别
6.如果需要最高的可用性和最低的延迟，请使用终一致性(Eventual Consistency)级别
7.如果需要更高的数据持久性而不想牺牲性能，可以在应用层创建自定义一致性级别
MongoDB API
MongoDB 3.4 与 Azure Cosmos DB 一致性级别之间的映射
| MongoDB 3.4 | Azure Cosmos DB (多区域) | Azure Cosmos DB (单区域) |
| Liner | Strong | Strong |
| Majority | Bounded Staleness | Strong |
| Local | Consistent prefix (一致性前缀) | Consistent prefix (一致性前缀) |
一致性保证：
1.当一致性级别设置为Bounded Staleness，CosmosDB保证客户端始终读取前一次的写入值，同时有一个过期窗口(Staleness Windows)
2.当一致性级别设置为Strong (强一致性)，过期窗口(Staleness Windows)为0，保证客户端读取写入操作的最新的值
3.对于剩余的三个一致性级别，过去窗口在很大程度上取决于你的工作负载。比如，如果在数据库上没有执行任何写入操作，则Session (会话一致性)，Consistent prefix (一致性前缀)和最终一致性 (Eventual Consistency)级别的读取操作，和Strong (强一致性)的读取操作，结果是一样的
