内存缓冲区

    想要编写一个App，需要存储大量的数据，用户信息、资源信息等，必要然频繁的访问数据库。然而数据库的访问工作很可能是一种远程的访问，频率过多的访问数据库会使服务器负荷过重，以APP的登陆操作为例，我们可以在Service层建立一个缓冲区，用来分担服务器的压力。具体想法如下：
    Service层主要负责业务逻辑，在用户登录的过程中，需要调用Dao层的方法访问数据检查用户传来的账号和密码是否正确，每有一个用户登录就需要访问一次数据库，如果在一段时间内登录用户的数量非常多时，服务器就会不堪重负，为了缓解这个问题，我们可以再Service层设置一个Map用来存储已经登陆过的用户信息。在最开始的时候，每一个用户登录都通过服务器访问数据库，但访问之后，服务器可以把该用户的账号密码等信息，存放在Service的Map里，在服务器没有关闭的情况下，该用户登录的时候服务器可以现在在Map中查询用户的信息，如果没有在进行数据库的访问，一定程度上降低了数据库访问的频率。
    **那么问题来了**，如果用户在第一次登陆后更改了自己的密码呢，由于内存Map中的信息更新不及时，该用户在第二次登陆的时候，服务器在Map中找到的密码始终与用户传过来的密码不相匹配，这.......这就尴尬了，只要你敢改密码，我就让你再也登录不上去。。。那后面还有一招啊
    我们可以设计一个侦听者模式，生成SQL语句直接操作数据库的类为发布者，Service层为消息的接受者，一旦有用户更改密码，发布者就会给Service层发布一条信息，Service层接收消息后，根据消息进行一定的处理，调整Map里面的数据。这样就保证了内存和数据库消息的同步性。
    **我们再来想想**，把所有已经登陆过的用户的信息都放在内存中真的合理吗？
    如果有成千上万的用户已经登陆过了，那这Map的长度未免有点太大了吧，如此占用内存，可不能美名其曰为服务器分压了呢，因此，我们可以通过配置的方式给这个Map设置一个最大的长度，每一个用户登录的时候我们记录下登陆的时间或者每登录一次就给频率个数加一，一旦达到了Map的最大长度，服务器就需要对Map进行一次清理，删除那些最后一次登录时间相隔最远的，或者是登录次数最少的用户。
    **那如果有多个服务器怎么才能保证多个服务器的Map信息的及时更新呢？**  
    比如：比如A用户，在S1和S2服务器都登陆过，S1和S2服务器都在service层中存储了用户的信息，某次在登陆S2服务器的时候一开心，把密码改了，然后又登陆了S1服务器，要是S1和S2服务器没能数据沟通，他又会被S1服务器拒之门外了。
    我们设置缓冲区的目的是为了给服务器分压，那既然有多个服务器是不是缓冲区的想法也应该调整调整了，可是万一有这种情况存在呢，据我浅薄的认知，是服务器之间有信令的传递，可以通知其他服务器自己对数据库的变更，具体什么的，就大家一起深入学习吧。