APP开发集群架构如何升级数据库备份配置？
APP开发定位处理方案示意图表9-6把所有LBS请求按照3个地区分片。
好了，本文APP开发公司关于APP制作数据库集群备份处理方法就分享到这里，谢谢关注，博纳网络编辑整理。
我们在APP项目开发中如何使用MongoDB处理LBS查询，为了保证高可用，开始阶段就推荐使用MongoDB的副本集架构。副本集架简单来说类似于MySQL的主从架构，一个主节点负责写，多个从节点负责读，通过MongoDB的内部机制，数据从主节点复制到从节点。但副本集中的主节点不是固定于某台服务器，而是通过集群中的服务器选举得到。深圳APP开发公司现就这些实际应用方法进行如下整理归纳，首先我们看看副本集的架构如图9 -35所示。
APP开发集群架构备份数据库升级示意图9-35 MongoDB副本集架构
随着业务的发展，MongoDB副本集慢慢会出现下面的问题。
·内存不够。
·读写压力过大。
·主、从复制延时过长
不同类型的App对LBS系统的读写压力完全不同。例如，对于美甲、家政类型的o2o类型 App，其更新和获取LBS数据的频率很低。但对于打车类App．因为其需要频繁地更新地理位置数据，LBS后台需要承担的读写压力比般App的读写App大，在打车类型快的公开的资料中LBS系统每秒的读写次数比居然达到4：1。
MongoDB写压力增大引发库锁问题。MongoDB3.0之前的版本会有库锁，库锁的意思是当多个客户端并发访问个库时，如果某个客户端正在进行写操作，其他客户端部必须排队等待。到了一定的并发量后，库锁对性能影响十分巨大。
MongoDB写压力增大也会引发主从复制延时过长的问题，对于某些类型的App来说是没法接受的，例如打车App。因为车子直都处于高速移动，司机的地理位置数据会在主节点更新。当乘客在从节点中查询附近的车子时，如果主、从延时过大，虽然从库上查询的车子位置是在附近，但车子实际的位置可能已经移动到l公里外。这就给乘客带来了不好的体验，造成乘客呼叫了车后，车久久不来。
以上问题的解决方案有下面两个
·MongoDB3. 0的WiredTiger存储引擎，该款存储引擎支持了文档级别的锁，但由于这款存储引擎不兼容MongoDB以前版本的数据，因此升级困难。
·MongoDB的分片架构。对于大多数LBS后台来说，这是最理想的解决方案。
APP开发集群数据库升级方法分片架构
分片架构可以把集群中大量的数据读写请求分散到多个片上处理，每个分片是副本集的架构。关于副本集的详细介绍，请各位查看本站分片要注意合理的分片规则，通过合理的分片规则把LBS请求合理分散到各个分片。对于LBS应用，一个常用的分片规则是根据用户所在的地区分片，例如打车App，一线城市的打车使用LBS的频率比二三线城市多，因此可以把所有用户的地理位置数据按照地区划分到不同的分片。由于MongoDB现在默认的分片策略还不能实现基于地理位置的分片，因此采用的是应用层分片方案。
下面展示了分片方案把所有LBS请求按照3个地区的划分在不同的分片如表所示。
下面展示了分片方案把所有LBS请求按照3个地区的划分在不同的分片如表所示。
APP开发定位处理方案示意图表9-6把所有LBS请求按照3个地区分片。
好了，本文APP开发公司关于APP制作数据库集群备份处理方法就分享到这里，谢谢关注，博纳网络编辑整理。
当前文章链接：/construction/appkaifa/1817.html
如果您觉得案例还不错请帮忙分享：
[声明]本网转载网络媒体稿件是为了传播更多的信息，此类稿件不代表本网观点，本网不承担此类稿件侵权行为的连带责任。故此，如果您发现本网站的内容侵犯了您的版权，请您的相关内容发至此邮箱【qin@198bona.com 】，我们在确认后，会立即删除，保证您的版权。
