在 MongoDB 上模拟事务操作来实现支付

有值说明刚才用户的 account 值已经操作过了，此时可以不用操作，如果没有再进行操作。这里利用了 LeanCloud 数据存储接口的按条件更新数据的功能（使用 query 参数）来保证操作的原子性，从而也解决了并发问题！这个 query 参数真得要夸一下，在 LeanCloud 还没提供这个功能之前，我们只能采用 log 表中的新旧值比对来解决数据一致问题，但无法避免并发问题，这样当用户数据错了，我们只能认为支付失败，然后进入人工干预环节，很是麻烦。

最后再说说我们和 LeanCloud 的相遇。最初是通过朋友圈知道了 LeanCloud，后来就一直关注着。也试过一些项目，发现开发应用真是方便许多。原本大量的后端需求都要自己研发，现在都省了，只需要专注于写应用端的代码，效率自然会提高一倍以上，开发迭代速度也上去了。当然也有过顾虑，生怕遇到一些特殊场景 LeanCloud 满足不了那我们就悲剧了！但后来看到一些知名的应用都在用 LeanCloud，心里也就安稳了，有前辈们踩过坑，有 LeanCloud 的技术支持做后盾，我们就这样选定了 LeanCloud。

随着项目的进行，我们从传统的后端服务接口开发变成了面向「Document」开发，服务端工作减轻了不少。虽然在数据设计中遇到一些复杂结构的问题，比如 Pointer 和 Relations 的问题。记得当时 Array 不支持 Pointer 的 include，所以考虑用 Relations，但在 LeanCloud 社区中又看到几个相关问题都推荐使用 Array 或者 Pointer，后来通读了相关文档对数据模型有了更深的理解，问题也就少了，所以说全面了解文档是至关重要的。

在 MongoDB 上模拟事务操作来实现支付

标签：point   利用   避免   人工   数据存储   比较   朋友   用户数   get