redis分担压力--短数据

背景说明

在营销服务场景中,很多拉新/引流的信息,这些信息还有一个特点：都是吸引眼球的信息(98%读)，而且信息的生命周期基本上都是1-3周就会大改,并且在其周期时间内,极多情况下,都是会反复变动.这种背景下,我们如果用rdms这种传统型,当然是可以满足需求的,但是我们需要考虑的是是否有更好的方案呢?

情况说明

基于背景说明的信息,我们得出结论数据格式变动大/业务响应速度快,我们需要一种灵活的方案来应对.我们的眼光坐落于nosql的特点,非常适中的匹配我们的业务场景,其中redis是最适合而且还是目前项目组大家都在用的,基本无缝接入了

技术类型特征总结

• 高频读
• 数据格式灵活多变

实战操作

代码参考(redis分支)

代码实例

代码分支更多侧重于描述怎么用,注意什么方面.大家根据思路来开展自家代码改造

落地总结

瞬时重建伪代码

• 锁最好用分布式锁
• 重建必须要加锁的原因是如果不加锁同时并发度如果是有10的话，相当于10个请求都是走一遍db而后对redis进行插入。第一点是竞态导致数据不一致问题。第二点是对db及所有资源都是无效加压。

Logger logger = Logger.getLogger("com.example.hkshardsphere.controller.CacheController");
logger.log(Level.INFO,"走缓存start");
MeatVO  meatVO = cacheStr2Data(key);

if(Objects.isNull(meatVO)){
    Lock lock = new ReentrantLock();
    lock.lock();
    try {
        logger.log(Level.INFO,"缓存重建开始");

        com.example.hkshardsphere.gencode.entity.User user = userService.getById(key);
        TestInfo testInfo = testService.getById(key);
        meatVO = new MeatVO();
        meatVO.setUser(user);
        meatVO.setTestInfo(testInfo);
        String jsonStrs = JSONUtil.toJsonStr(meatVO);
        cacheService.save2expre(key, jsonStrs,30+new Random().nextInt(10));
        if(cacheService.isLiveKey(key)){
            logger.log(Level.INFO,"访问缓存开始");
            meatVO = cacheStr2Data(key);
            logger.log(Level.INFO,"访问缓存结束");
        }
        logger.log(Level.INFO,"缓存重建结束");

    }finally {
        lock.unlock();
    }
}
logger.log(Level.INFO,"走缓存end");
return meatVO;

参考内容

求文推荐

觉得文章对你有帮助，记得点赞收藏关注，一键三连