部标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部标监控平台的架构设计系列