GPS部标监控平台的架构设计(十一)-基于Memcached的分布式Gps监控平台

部标gps监控平台的架构，随着平台接入的车辆愈来愈多，架构也面临愈来愈大的负载挑战，咱们固然但愿软件尽量的优化并可以接入更多的车辆，减小在硬件上的投资。可是当车辆增多到某一个临界点的时候，仍然要面临的三个问题：

1）链接的限制

      服务器软件接入终端的链接数是有限的，不管如何优化，都是有限的，接入的增多就会排队，超时timeout重置reset等问题就会出现;

2）部标808服务器软件的内存限制的问题

      内存的限制，服务器操做系统中一个进程所承受的内存是有限制的，超过则致使服务器软件进程内存溢出而退出。

3）数据库承受的并发压力和数据压力愈来愈大，随着gps数据和报警数据海量增加，数据库备份、数据库服务器响应速度变慢，进而网站的响应速度等都会变慢。用户体验效果会愈来愈差。

对于第一个问题，咱们采用多个分布式的gps服务器或者负载均衡来解决，对于后面两个问题，咱们引入Memcached这个分布式的缓存服务器，来解决内存和数据库并发压力这两个问题，关于Memcached的介绍，网上有不少，官方中文网站：http://memcache.com.cn/。

这里重点说一下，Memcached在部标监控平台架构中的位置和应用。

1.GPS监控平台包含了808服务器、809服务器、web服务器、油耗里程定位计算服务等多个子系统，这些系统对于实时数据和静态数据的调用特色是高频次调用，基于Memcached的分布式缓存，解决了各个子系统之间共享缓存的问题，也解决了采用本地缓存形成的数据同步困难的问题，如车辆信息中的车牌号用户在web界面上进行更改，采用本地缓存，则只是更新到web子系统，若是采用EHcache，须要作比较复杂的配置，这彻底不必。

2.不一样于电子商务平台的订单数据对于事务一致性要求很高，监控系统的特色是实时，它对于数据的时效性要求较高，因此即便Memcached没有集群，是一个单点的缓存服务，即便缓存服务不运行或者运行故障，咱们在架构设计的时候，只要考虑到这点，整个系统在Memcached故障的状况下，仍然能够运行或者支撑住一直到Memcached恢复服务。

3.对于gps监控，咱们须要看到实时的gps数据和报警，这些实时的数据，咱们能够放在内存当中，而不是直接保存在数据库中，这样能够减小数据库的压力。运行在不一样进程的模块，能够共享实时的gps数据，而不用不断的查询和更新数据库。因此咱们把Memcached做为一个中央缓存系统，而后对Memcached client封装成一个ICacheService接口的标准Memcached实现，里面作了Memcached故障失效的判断，由各个子系统引用，各个子系统共享信息，一个系统负责更新和维护数据，因为数据放在缓存服务器上，这样808gps服务器的内存压力就大大减少了。这样咱们能够肆无忌惮的调用车辆信息而不用担忧频繁查询数据库的性能损失了。

Memcached架构以下图所示：

Memcached做为服务器端，要想调用，还须要各个模块集成Memcached缓存，网上提供了.NET和.java的客户端，咱们须要结合本身系统的数据结构和架构，封装成面向对象的缓存服务。

GPS部标监控平台的架构设计系列文章已经写到十一章了，若是须要阅览之前一到十的文章，请阅读》GPS部标监控平台的架构设计系列