本系统为客服系统，对接了后端智能辅助系统；当消费者发文字时（问题），本系统会将文字发给辅助系统，辅助系统会返回相关回答，供客服参考。3、4两步均采用的SSE，本系统调用智能辅助时纯透传没有额外逻辑。本来我们系统基于Spring的RestTemplate写了一套类似feign的框架，简化调用后端。

运维接到用户反馈无法登录，拉我上线一起定位。首先我们先拉上用户进行复现，发现登录接口超时导致登录失败。遂让运维先查查有无错误日志，我这边通过啄木鸟(调用链查询系统)确认是哪一段耗时。还未等我打开啄木鸟，运维就发现有大量数据库连接报错。虽然该报错并不是登录服务(下图服务C的)的，但我知道登录接口肯定受这个报错影响了，因此就不再查看啄木鸟直接定位该报错了。且该接口QPS有点高。

背景背景如上一篇文章《request.getRequestDispatcher().forward()的妙用以及DispatcherType 对Filter配置的影响》,项目要将服务从虚拟机从迁入docker中，方便自动化部署以及弹性扩容等。闭坑一-应用看到的ip及port是docker的内部ip、端口，外部无法访问应用看到的是docker内部ip及端口，这个是宿主机虚拟出来的，对外部不可见；如果

背景微服务模式下，一次请求可能会经过多个服务。如果没有日志链将单次请求的日志串起来，定位问题时很容易陷入海量的日志中，无法快速定位问题。sleuth是spring cloud中日志链（调用链解决方案），引入该依赖后，日志中会自动添加（traceid，spanid）。当获取到traceid后，可以在kibana或者其他日志收集系统中，精确定位到本次的所有日志。sleuth基本原理很简单，就是在入口生

背景接手了一个系统，该使用了HAProxy + Sentinel +redis方案，该方案在redis发生主从切换后，因为应用层启用了连接池，老连接连的仍然是redis的“老主节点”。当应用层获取到这些老连接进行写操作的时候，会抛出异常。org.springframework.data.redis.RedisSystemException: Error in execution; nested e

项目组最近准备将Redis由哨兵模式组网切换到集群组网，切换后应用访问redis时报错，“Pipeline is currently not supported for JedisClusterConnection.”。初步定为Jedis在集群模式下不支持pipeline。org.springframework.data.redis.connection.jedis.JedisClusterCon

项目组准备将自建的redis切到公司云平台的redis服务；自建的redis用的是哨兵模式，而云平台的提供的redis服务用的是集群模式。切换前先分析redis用到了那些功能，redis集群模式下是否兼容。分析代码时发现，用到了RedisMessageListenerContainer，该类用于监听redis发出的消息(redis的发布订阅功能)。我们使用到了redis键过期通知的特性，来实现超时

我司有一套开源使用规范，衰退期的软件或版本需要升级到GA版本。我们ES服务端是6.8.x的，根据ES官方推荐版本，springdataelasticsearch使用的是3.2.x，配套的springboot版本为2.2.x.我们当前使用的版本已经比较老了，我们需要将springboot升级到2.6.x，并将springdataelasticsearch升级到4.3.x。..............