提示消息放在 remind 表里面，每个用户一条记录，ehcache 做缓存，只有缓存更新时才去读库，所以超过 99% 的时间都只读内存

我是这么理解的，对不对？ 使用CacheKit中的put方法，将user_id作为key，是否有新消息提醒作为value缓存起来；如果该用户被@的时候，就更新缓存中该用户user_id对应的value值为true。用户访问页面时，是这样的逻辑：根据缓存中是否需要提醒的值来判断给前台什么样的反馈。如果为true，前台反馈给用户有人@你了；用户点击查看提醒消息时，将该用户是否有提醒的缓存数据值更新成false。

@JFinal 好的,我试一下

@nbjgl 这个方法好像也可以,只是没法显示@的数量?

比如有a、b两个用户@了你，那你就把缓存中的value设置成a#b，取出来的时候，分割字符串就行了啊。缓存的value不一定非要是boolean……用户查看消息时候，把对应的缓存remove掉，下次读取缓存时候如果值为空就说明没有新消息了。

@JFinal 这样对不？

@nbjgl 没那么麻烦，我直接贴出 remind 表的设计
CREATE TABLE `remind` (
`accountId` int(11) NOT NULL COMMENT '用户账号id，必须手动指定，不自增',
`referMe` int(11) NOT NULL DEFAULT '0' COMMENT '提到我的消息条数',
`message` int(11) NOT NULL DEFAULT '0' COMMENT '私信条数，未来考虑加粉丝增加个数',
PRIMARY KEY (`accountId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

referMe 这个字段用于存放 @提到我 数量，message 用于马上要做的私信功能，你还可继续添加字段用于存放其它类型的数据。
1：每次有 referMe 到来时让这个字段加1
2：用户访问网站的时候会去缓存取这个 remind model，如果没有则去数据库读，如3：果字段值大于 0 则显示 tips 提示框
4：当用户点击了 tips 提示框的链接，或者进入过 /my/referMe 这个 action 将 message.referMe 的值置为 0即可

@nbjgl @飞羽 我个人对缓存的使用的基本路子是：
1：先不使用缓存，完全无视缓存，用数据库保存数据，并实现功能
2：在需要缓存加速的地方，引入缓存
3：缓存只在 service 层中引入，service 层以外完全不知道缓存的存在

这样做的好处是：
1：以数据库为核心，缓存只在适当的地方做辅助，数据可以持久化，避免了缓存断电丢失的情况。数据库存放数据更加结构化，便于管理，而缓存结构化差，不易于管理
2：缓存只在业务层中，业务知道自己如何管理缓存，例如某个业务的 getList(...) 方法使用了缓存，那么在这个业务的 delete()、update() 方法就可以精准地更新缓存，缓存管理统一在了当前的业务层之中，不会散布到各处，易于管理，不易出错
3：缓存对于业务的调用者完全透明

@JFinal 波总波总，我比较倾向于有提醒或者私信的的时候，缓存中没有数据则count获取数据生成实例， 这样就少了一张remind表了。这种做法有什么坏处吗？而且我老觉得每次有referMe到来的时候让这个字段加1，这种边读边写做法会出问题。

@林栋 用 count 获取，你需要在私信等需要生成提醒的字段中添加字段，例如添加一个 isRead 字段，然后你需要维护这个字段，数据量大以后这个字段会占用一定空间，并且 count 也需要消耗性能
referMe 到来的时候字段加 1 ，不是关键数据，多出一个少出一个无所谓，而且这个值是访问后立即清零的，相当于随时能回到正确的状态，你在实践中去写代码的时候就能体会现这样设计的好处

@JFinal 多谢多谢,我现在就是先实现了功能,慢慢一点加其他的

@飞羽 逐步迭代是最好的发展方式

@JFinal 我觉得私信这类还是需要一个isRead字段的，不过具体业务具体分析吧，通过count生成referMe只是缓存中没有需要初始化才用到的。 第二段这个随时回到正确状态很赞，期待工作中出现一个能用这种模式解决的问题。感谢波总。