微服务设计指导-让Redis循环写入时提高10倍的技巧_bitfieldsubcommands.bitfieldtype.unsigned()

简介

有微服务的架构不代表性能好，而使用微服务的架构必须要求性能好。这句话不矛盾。矛盾在外面很多人认为微服务架构代表高并发，实际上不是。我们有“书面微服务”和“实际微服务”之说。比如说网上大量教人把httpConnection或者是FeignClient的timeout改成30秒就不会超时了？那这要什么微服务呢？微服务解决的到底是什么呢？

绝大多数人忘记了微信的本质是用来解决什么问题的。

互联网应用在To C端有6秒之说，即一个小程序/APP应用打开和加载过程>6秒，肯定新用户就不会再去用了，4秒算平均水平，一般大厂都是做到加载页面1秒。

各位要知道，任何一个“查询”式页面打开一秒，全站可能存在上千、上万个API，有时一个页面是需要通过几十个API组合在一起的。因此对于API在系统内我们互联网界的要求是约束在“一根API需要在前端万级并发的情况下+系统每张单表千万数据的Data Volumn下响应时间在100毫秒之内的“。

这就是1秒钟说的由来。

• To C端界面加载1秒；
• 任何微服务（即时响应类）要在100毫秒内

这是因为，你的应用上会有不少外联、不少回调、不少地图、配送、支付这种调用。它们都会对我们的应用造成“级联式雪崩”。

为了避免复杂系统的雪崩就需要及时“熔断、限流、升级”。这就是微服务的本质。

如果已经用了微服务架构、实际发觉这边老是超时，于是很多人一味地去放长这个连接时间自以为就解决了。

这样的人群占比大概超过90%（业界有统计）。

因此用了微服务即代表着对于开发的技能要求水平更高，任何可以提高100毫秒的地方都值得去做。

微服务架构里特别强调一个哲理“勿以善小而不为之，勿以恶小而为之”。

Redis在for循环里写大量数据的梗

通常情况我们经常会碰到要把千、万条数据一次写入Redis，在互联网应用场景中，我们经常把百万、千万级数据也会往Redis里塞，如：Redis Bloom。

经典的写法都是以下这样的：

@Test
    public void testForLoopAddSingleString() throws Exception {
        long startTime = System.currentTimeMillis();
        String redisValue = "";
        for (int i = 0; i < 10000; i++) {
            StringBuilder redisKey = new StringBuilder();
            redisKey.append("key_").append(i);
            redisValue = String.valueOf(i);
            redisTemplate.opsForValue().set(redisKey.toString(), redisValue);
        }
        long endTime = System.currentTimeMillis();
        long costTime = endTime - startTime;
        logger.info(">>>>>>test batch add into redis by using normal for loop spent->" + costTime);
 
    }

运行后得到如下输出：