yuantong 写道
d-jasonlee 写道
hilliate 写道
你这个帖子估计很快就要被JE和谐掉。
回答问题,我也是新手,但是我面对这种情况,毫不犹豫,给你所谓的po增加个count属性。
要不你就返回一个hashmap(不推荐)。
问题很菜,见笑了!
你的意思是说在用户表中加入一个字段(例如叫count)来标记他被多少人关注?
这样就是有人在关注他的时候update一下这个用户的这个字段,有人解除关注的时候也update一下这个用户的这个字段。
不知我这么理解对吗?
太耗数据库资源了
相比起显示count的次数来讲,我想关注和取消关注的次数应该是少好几个数量级的.
比如说,这个产品在1个月能有1万个用户,平均每个用户关注50人(这个平均关注度已经很高了吧).那么在这一个月中,需要50万次update操作.假如仅在登录首页的时候要显示count(这应该非常少了吧?事实上可能会很多地方都显示).按每个人每天进入首页1.5次.那么也给查询45万次.(要注意的是,当用户很多的时候,这个查询的系统消耗非常恐怖).
最重要的是,当你去关注某人的时候,你还会看到对方的count的.所以每一次的update都意味着至少两次的查询(查询对方,和刷新后显示自己的,这还不包括大家串门时到别人首页时看到的别人的count).
所以说,count的query和count的update次数差一百倍绝对不为过.
我还是建议冗余count这个字段.只要注意update的时候行锁定而不是表锁定就行.
至于为什么不去用应用缓存,而是要采用数据库字段冗余,这是因为count只是一个字段.应用级别的缓存,最好还是缓存一个业务单元.count有点过小了.比如说,经过分析,你发现这个服务中,30-50% %的请求都只是针对5%的用户的信息进行请求的,此时你就需要去缓存这5%的用户的完整信息.而不是很广义的去缓存100%的用户的某个信息.
|