yhzhu的随手记

灰度发布是一种常见的上线策略。如果灰度发布时间较长，且在灰度期间各分组共用缓存，那么该过程中可能会面临缓存数据一致性的挑战。本文将讨论在灰度发布过程中导致缓存数据不一致的问题和解决方案。

项目背景

随着业务的快速发展，我们原有的 session 存储方案 Memcached 逐渐显露出一些瓶颈，主要体现在以下几个方面。：

• 扩展性受限：Memcached 集群不支持分片，要分片需要在客户端实现分片逻辑，扩容和缩容操作繁琐，运维成本较高，难以满足业务快速增长的需求

在Spring项目中，RestTemplate简化了HTTP请求和响应的封装，并且执行了Restful原则。底层HTTP请求由HttpURLConnection,Apache HttpComponents和OkHttp三种实现。最近我们在使用Apache HttpClient作为RestTemplate底层实现时，由于使用不当导致耗时瞬间升高

基础组件是我们系统构成的关键要素，包括中间件SDK、基础架构组件等。它们为系统提供了核心功能和基本服务，为业务逻辑的实现提供支持; 近几年多做了一些基础组件的升级，有些经历了较长的升级周期，也有的一次上线直接成功，还有个别组件升级失败了，目前仍然在寻找改进方法；

背景

在需要消息队列的场景中，生产端和消费端会事先就消息体格式达成共识确保生产端发送的消息在消费端能正常识别；如果生产端和消费都是Java项目，我们通常会定义消息体的Jar，让生产端和消费端都引用Jar确保消息的一致性；但在跨语言消息传递中

在大型互联网项目中我们经常会用到消息队列(简称MQ)；主要用在异步消息，应用解耦，流量削锋等场景；在实际应用中经常需要保证消息的可靠投递

引言

我们的支付系统最初作为单体应用的子模块存在，随着业务规模扩大，高并发下的掉单和重复支付问题频发，日均人工对账成本高达数小时。为解决这些痛点并支持未来业务扩展，我们决定将支付系统重构为独立的微服务架构，核心目标包括：

转载马伯庸一篇短篇小说 「寂静之城」 ；记得好多年前看的时候认为是科幻小说，现在想想还是自己太年轻

上周某核心服务上线过程中内存瞬间飙升，导致上线失败。经查是一个三年前的bug引发的。

Sharding-JDBC(ShardingSphere)作为分布式数据库中间件,在Java的JDBC层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务。引入sharding-jdbc-spring-boot-starter可以快速完成与springboot的集成; 但是默认情况下只能支持到一个数据库，如果支持多数据库，需要做部分扩展；本文记录支持多数据库所做的扩展。