yhzhu的随手记

最近我们进行了一个项目的重构，其中一个重要目标是减少数据库访问的负载。由于核心数据库被多个应用程序访问，并且数据库服务器只能对整体数据库流量进行监控，我们需要在应用程序端监控不同应用程序的SQL请求，并将其与现有的指标集成在一起

随着业务规模的增长，我们的缓存系统面临扩展性和运维效率的挑战。近期我们团队将缓存系统从Memcached迁移到Redis集群。

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

项目背景

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

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

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

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

背景

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

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

引言

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

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