bytearch

当业务发展到一定程度，原有老系统出现瓶颈，或者公司技术栈出现变化(例如PHP转Java语言)，需要重构，然而重构同时线上业务又必须稳定运行。那么如何平滑过渡，降低重构出现问题的风险，显得尤为重要。本文就来聊一聊这个问题。

前段时间log4j安全漏洞事件，可以说掀起了一场”血雨腥风“，正好最近做了一个项目对安全要求特别高，对有安全漏洞开源组件做了统一修复。特此总结，希望对大家以后选择组件版本时有所帮助。

一、概述mysql分库分表一般有如下场景垂直分表(将表分为主表和扩展表)垂直分库(将表按业务归属到不同的库,如订单相关的放到订单库,用户相关的表放到用户库等,这也是我们常说的权限回收其中的一部分)水平拆表(当数据库整体瓶颈还未到时，少量表到达性能瓶颈)水平拆库 & 拆表(数据整体性能到达瓶颈,单一写入出现性能瓶颈)其中1，2相对较容易实现,本文重点讲讲水平拆表和水平拆库,以及基于mybatis插件方式实现水平拆分方案落地。二、水平拆表在《聊一聊扩展字段设计》 一文

1、概述当数据库分表或者分库后，如何能够快速拿到一个唯一序列号，是经常遇到的问题。今天我们就来讨论一下如何设计分布式全局唯一永不重复Id生成器。2、业界都有哪些做法UUID(机器的网卡 + 当地时间 + 一个随记数 => UUID)。优点：本地生成，生成简单，性能好，没有高可用风险缺点：长度过长，存储冗余，且无序不可读，查询效率低不建议使用采用一个集中式ID生成器，它可以是Redis，也可以是ZooKeeper，也可以利用数据库的表记录最后分配的ID。缺点: 有网络调用,并且.

1.为什么要灰度发布解决系统重构老系统向新系统平滑迁移按流量控制灰度,可以降低风险,有问题只影响极少了用户2.设计思路首先看看openresty指令执行顺序指令说明init_by_lua*初始化 nginx 和预加载 lua(nginx 启动和 reload 时执行)init_worker_by_lua*每个工作进程(worker_processes)被创建时执行，用于启动一些定时任务，比如心跳检查，后端服务的健康检查，定时拉取服务器配置等ssl_cert

一、概述不知不觉,2020已经要过去一半了,实属惶恐!今天给定了个flag,准备写一套系列文章《浅谈千万级系统重构》,抛开微服务技术栈不谈(未来将是另外一个系列)曾经简单的写过一篇《重构方案设计》,该系列文章相当于该篇文章的具体落地方案,目标本月完成本系列课程。二、重构那些事单体架构随着业务的发展,单体架构问题逐渐暴露业务越来越复杂，单体架构扩展性不足，业务扩展带来的代价越来越大数据库单点写入瓶颈,mysql数据量太大查询效率不高改动一个点可能导致其它地方出问题所以系统重构显得尤为

1. 背景​ 工作中我们常常有需求需要加字段,如果数据库数据量比较大,新增字段耗时较长,导致性能下降，甚至出现锁表等问题。​ 添加扩展字段, 常见的做法有,动态添加字段添加扩展表json方式存储xml方式存储​ 这里我们聊聊基于KV行存储和基于按位存储。2. 基于KV水平存储场景:例如现在有张订单表,需要新增field_1,field_...