jtea

摘要： # 前言 本篇来介绍一下redis pipeline，主要是由于最近一次在帮开发同学review代码的时候，发现对redis有个循环操作可以优化。场景大概是这样的，根据某个uid要从redis查询一批数据，每次大概1000个key左右，如果查得到就返回，否则查db，然后写回缓存。由于每次要查的key 阅读全文

摘要： # 前言 在面试这一篇我们介绍过[CountDownLatch和CyclicBarrier](https://github.com/jmilktea/jtea/blob/master/%E9%9D%A2%E8%AF%95/CountDownLatch%E5%92%8CCyclicBarrier.md 阅读全文

摘要： ## 背景 生产上有个导报表功能，工作了很长一段时间一直都很稳，没出现过什么问题，最近运营同学突然反馈导出来的数据和实际的对不上，经过排查发现导出的数据有重复，也有的没导出来。 由于我们提前生成好数据（每天会truncate重新生成），所以导出的逻辑非常简单，不需要关联很多表捞数据，只需要从一张表查 阅读全文

摘要： 要解决多线程并发问题，常见的手段无非就几种。加锁，如使用synchronized,ReentrantLock，加锁可以限制资源只能被一个线程访问；CAS机制，如AtomicInterger,AtomicBoolean等原子类，通过自旋的方式来尝试修改资源；还有本次我们要介绍的ThreadLocal类 阅读全文

摘要： # 前言 为了更好的进行开发和维护，我们都会对程序进行分层设计，例如常见的三层，四层，每层各司其职，相互配合。也随着分层，出现了VO，BO，PO，DTO，每层都会处理自己的数据对象，然后向上传递，这就避免不了经常要将一个对象的属性拷贝给另一个对象。 例如我有一个User对象和一个UserVO对象，要 阅读全文

摘要： ## 问题描述 分享一个发版过程服务报错问题，问题出现在每次发版，服务准备下线的时候，报错的位置是在将任务submit提交给线程池，使用Future.get()引发的TimeoutException，错误日志会打印下面的"error"。伪代码如下： ``` List>>> futures = new 阅读全文

摘要： 随着时间推移，参与开发的人员越来越多，项目代码也会越来越复杂，需要我们有意识的定期对代码进行优化，有问题及时解决，避免技术债务越积越多。 这不本人就遇到一个服务启动慢的问题，印象中服务启动是比较快的，一般也就20几秒，但这次开发一个需求发现服务启动要接近1分钟，这对本地开发调试，测试同学测试都是非常 阅读全文

摘要： # 前言 现有主流消息中间件都是生产者-消费者模型，主要角色都是：Producer -> Broker -> Consumer，上手起来非常简单，但仍有需要知识点需要我们关注，才能避免一些错误的使用情况，或者使用起来更加高效，例如本篇要讲的kafka分区分配策略。 在开始前我们先简单回顾一下kafk 阅读全文

摘要： 简介 限流顾名思义是对流量大小进行限制，防止请求数量超过系统的负载能力，导致系统崩溃，起到保护作用。 现实生活中限流也随处可见，节假日出门旅行的人数会剧增，对于旅游景点来说往往会不堪重负，如果不进行人数控制，对整个景点的压力会非常大，游客的体验也会非常差，还容易出现安全事故等危险。 同样的在一线城市 阅读全文

摘要： 前言 "redis是单线程的" 这句话我们耳熟能详。但它有一定的前提，redis整个服务不可能只用到一个线程完成所有工作，它还有持久化、key过期删除、集群管理等其它模块，redis会通过fork子进程或开启额外的线程去处理。所谓的单线程是指从网络连接(accept) -> 读取请求内容(read) 阅读全文