04stone37

原创 订单系统设计 —— 订单管理

文章目录一、方案背景1.1 考虑因素1.2 数据特点二、方案演进三、MySQL架构3.1 单库单表3.2 读写分离3.3 垂直拆分3.4 数据归档/冷热分离3.5 分库分表方案1：路由表方案2：哈希四、MySQL + NoSQL架构4.1 MySQL + ES4.2 MySQL + ES + HBase五、未来预期: NewSQL一、方案背景  订单系统是存在于各行各业的一个很基础、核心的业务系统。随着互联网的发展，订单系统的管理方案也在不断变化，订单数据规模的膨胀、用户对数据的重视，以及新的技术等都会

原创 订单系统设计 —— 数据同步与监控

文章目录一、方案背景1.1考虑因素1.2 数据特点二、增量同步方案2.1 并发消费2.2 顺序消费2.3 1:N关联数据三、存量同步方案3.1 并发同步3.2 基于视图同步四、监控与补偿机制4.1 延迟监控4.2 补偿机制一、方案背景  当订单数据量规模足够大或查询统计足够复杂时，通常会采用MySQL + NoSQL的架构方案，这种方案需要将MySQL中数据同步到其它介质，比如HBase、ES，或者阿里云的TableStore等。订单数据的同步面临着诸多挑战，尤其是异构介质，下面会从”数据同步面临的挑战

原创 SQL耗时统计方法

SQL耗时统计方法方案1：AOP方案2：Mybatis插件方案3：使用连接池内置的监控方案1：AOP@Aspect@Component@Slf4jpublic class MapperAspect { @AfterReturning("execution(* cn.xbmchina.mybatissqltime.mapper.*Mapper.*(..))") public void logServiceAccess(JoinPoint joinPoint) { log.info(

原创 Redis使用场景

文章目录场景1：基数统计方案一：Set方案二：Bitmap方案三：HyperLogLog（推荐）场景2：排序方案一：List方案二：ZSet场景3：LBS场景GEOGeoHash编码编码过程使用注意问题1：突变性问题2：边界性场景4：二值状态统计方案一：Bitmap场景1：基数统计  基数统计是指统计一个集合内不重复的元素，常见应用场景有日活DAU、月活MAU、网页UV等；方案一：Set特点：存储统计元素、精确统计，不适用于海量数据场景，占用内存且会阻塞Redis主线程；说明：如果一定要使用se

原创 订单系统设计 —— 数据一致性

文章目录一、方案背景二、技术方案2.1 全异步方案方式一：事务消息方式二：Binlog消息2.2 全同步方案方式一：AT模式方式二：TCC模式2.3 混合方案一、方案背景  订单系统是每个公司最核心的业务系统，订单逻辑执行过程中会和多个业务系统交互，如何保障订单系统和其它业务系统数据的一致性是订单系统的核心问题，数据的不一致性可能导致业务无法正常流转，甚至产生资损。二、技术方案2.1 全异步方案  适用场景： 资源充足、不需要实时得到反馈的场景；方式一：事务消息方式二：Binlog消息2

原创 订单系统设计 —— 分页查询

文章目录一、产品设计1.1 分页设计1.1 深度随机跳页1.2 小范围跳页1.3 滚动分页二、技术方案三、 DB规范一、产品设计1.1 分页设计1.1 深度随机跳页  产品设计不合理是导致深度分页查询的一个重要原因，比如下图所示的深度随机跳页设计方案，如果没有特殊原因，正常情况下应避免使用。一方面，随机跳页实际意义有多大有待考究；另一方面，随机性会加大后端的难度，如果随机跳页的页码很大，有可能导致查询超时，甚至异常，反而影响产品的稳定性以及用户体验。1.2 小范围跳页  小范围跳页涉及方案允许

原创 订单系统设计 —— ABA更新

ABA更新问题  ABA更新问题就是旧值覆盖新值问题，具体是指先后有两个不同的请求来更新同一个订单，请求1要将订单值更新为A，请求2要将订单值更新为B，由于网络超时等原因，最终请求2的更新结果被请求1覆盖/最新值被旧值覆盖的情况，如下图所示：原因分析  订单系统是电商系统中最重要的一个子系统，很多系统都需要更新订单的信息，比如支付系统、物流系统等。在高并发的情况下，在短时间内可能存在多个不同的请求同时更新同一个订单的情况，如果网络不稳定或者某时刻负载过高等情况，就可能导致订单的最新值被旧值覆盖的情况

原创 订单系统设计 —— 重复下单

设计感悟架构是演化出来的，不是设计出来的。架构设计就是一个持续迭代改进的过程。没有完美的架构，只有平衡的架构。架构设计过程中，不要过于追求单点的完美，而是追求多点的平衡。...

原创 订单系统设计 —— 订单号设计

订单号特性唯一性：每个订单号全局唯一代表一个订单；安全性：订单号不能透露订单量、运营规模等业务信息（数据安全性）；高性能：订单号的创建成本越低越好；扩展性：能够较好的支撑后续业务发展变大带来的分库分表、订单长度扩展等场景；业界一些方案方案1：数据库自增ID（不推荐）  基于数据库主键ID自增的特性生成订单号，不推荐此方案的原因有如下几点：不安全：订单号能够反映出系统的订单量，存在业务数据外露的风险；性能问题：需要数据库插入一条记录获取主键ID，性能受限于数据库，且存在单点；扩展性：

原创 分布式事务理论与实践

一、产生背景业务服务化拆分，原本一个服务能完成的业务操作现在需要跨多个服务；分库分表，写操作可能跨多个数据库；二、理论基础2.1 2PC协议角色说明事务管理器：负责分布式事务的发起与结束，以及失败重试等（事务发起方）；资源管理器：本地事务涉及资源的管理（事务参与方）；协议过程阶段一：事务管理器开启分布式事务，通知资源管理器准备资源；（Prepare）阶段二：事务管理器判断资源准备情况，如果所有资源管理器都已经准备好资源，则通知资源管理进行提交；否则，进行回滚；（Comm

原创 HBase总结

简介  HBase是面向列的分布式存储系统（NoSQL数据库），是对Google论文BigTable的实现，具有数据存储量大、高性能、高扩展等特点。（BigTable是对HBase最形象的解释，大宽表，支持百万级列、亿万级数据，动态列）数据模型...

原创 一致性哈希算法

解决问题  传统的数据路由/分片的做法是将key的哈希值对N取模，N为槽位数（槽位数即机器数）。这种方案的问题在于最终的路由结果会跟着机器数量的变化而变化（扩容、缩容和宕机等），从而导致请求查询不到数据或者请求出错等情况。  问题：机器数作为槽位数，当机器数量发生变化时，导致大量请求重哈希。一致性哈希算法  算法思想：槽位数取无限大的固定值，不再与机器数产生关联，如下图所示，这样无论机器数量如何变化，请求的哈希结果是不变的。机器与槽位的关系既可以通过算法分配，比如均分、平均轮询等，也可以通过映射表来

原创 Netty内存管理

PoolChunk作用： 8K - 16M范围的内存分配，分配容量为PageSize的整数倍，PageSize默认为8K；基本概念maxOrder：二叉树的最大深度；chunkSize：PoolChunk的容量，默认为16M，即根节点的可分配容量；chunkSize = PageSize * 2^maxOrder内存管理  Page是PoolChunk内存管理的基本单元，PoolChunk通过完全二叉树的方式管理内存，如下图所示，每个节点的可分配内存为其包含的叶子节点内存之和，内存分配分为两

原创 分布式强一致算法 —— Raft算法

背景  Paxos算法是最早的强一致性算法，1990年被Leslie Lamport提出，但是由于其难以理解和实现，导致没有被广泛使用。因此，2013年Raft算法被提出，功能与Paxos算法相同，更易于理解，实现简单，因此迅速被广泛推广使用，已经成为当前主流的强一致性算法。（从CAP角度，Raft算法选择了CP，舍弃了A，选主期间会出现短暂的不可用）Raft算法整体流程  Raft算法可以分为Leader Election选主和Log Replication日志复制两部分。算法的整体流程是：首先，

原创 CAP与数据一致性

CAP定理一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三项中的两项。Consistency（数据一致性）：分布式场景下，只要存在数据冗余/副本，就需要考虑数据一致性问题；Availability（系统可用性）：系统/服务的可用性，一般通过不可用时间来衡量，如下所示；Partition Tolerance（分区容错性）：网络出现局部故障时（如丢包、乱序、抖动、甚至是网络分区节点 cras

原创 RocketMQ总结

路由管理  NameServer是RocketMQ的路由中心，负责为Producer和Consumer提供Topic的路由信息。

原创 缓存 —— Redis总结

持久化机制  Redis是内存型数据库，为了避免应用重启、挂掉或断电等情况导致的数据丢失，Redis提供了持久化机制，即把内存中的数据持久化到磁盘，提升数据的可靠性。Redis提供了两种持久化方案：RDB持久化和AOF持久化。RDB持久化  RDB就是某时刻内存数据的快照，用于机器重启或者从机全量同步。RDB持久化过程为：创建一个单独的子进程；子进程启动后开始将内存数据dump到临时文件；当拷贝完成后用临时文件替换现有的RDB文件（为了保证数据文件的完整性）；AOF持久化  AOF相当

原创 主从数据库一致性问题

原因  数据库集群的主从数据同步存在延时，延迟期间从库上的读请求会读取到不一致的数据，如下图所示。（不管同步还是异步，只要存在数据冗余就存在数据一致性问题）解决方案  整体思路：数据库的主从同步可以实现数据的最终一致性，延迟时间一般在几毫秒以内，因此可以按照业务对数据不一致时间的容忍程度设计对应的方案。对于绝大部分业务来说，比如订单、消息、搜索等场景，这些业务场景下是可以容忍几毫秒的延时，因此可以直接忽略数据不一致问题；对于不能容忍几毫秒的不一致性的业务，则需要强制性读主。强制性读主太过暴力，

原创 缓存 —— 先数据库还是先缓存(2)

  到底是先操作数据库还是先操作缓存，取决于哪种方案可以避免数据不一致，或者数据不一致的概率更低。下面的分析会基于Cache Aside策略展开，为什么基于Cache Aside策略，请查看博文“缓存更新策略”。方案1：先缓存再数据库  先缓存再数据库的方案，在并发读写情况下，会出现数据不一致的情况，如下图所示。而且，这种不一致情况会伴随着并发量的上升而严重（换句话说，并发量越大，出现的概率越大）。方案2：先数据库再缓存  先数据库再缓存的方案，在删除缓存失败的情况下，会出现数据不一致的情况，如下

原创 缓存 —— 缓存更新策略(1)

Cache Aside缓存策略读请求处理策略缓存命中，直接返回缓存数据；缓存未命中，从数据库加载数据，更新缓存；写请求处理策略（不同点）先更新数据库，然后删除缓存；数据不一致情况情况1： 写请求处理期间，并发的读请求读取到旧数据，写完成后缓存更新到最新数据；（最终一致性）情况2： 读请求处理期间，并发的写请求更新数据，导致缓存最终数据为旧数据；（无法实现最终一致性，实际情况中发生的概率极低，因为需要读请求的处理时间大于写请求处理时间，并且缓存失效，正常情况写请求处理时间大于读

原创 SQL语句执行过程

SQL执行过程  SQL 语句在 MySQL 中的流程是：SQL 语句→缓存查询→解析器→优化器→执行器，如下图所示：连接器  作用： 身份认证、权限校验、连接管理、以及安全管理；查看连接SHOW PROCESSLIST;Id：连接id；db：连接使用的数据库名称；Command：线程正在执行的命令类型；Sleep：线程正在等待客户端发送命令；Query：线程正在执行查询；Locked：线程正在等待锁释放；Sorting Data：线程正在对结果排序；Sending Dat

原创 InnoDB事务隔离级别

前因后果由来：为了解决并发事务带来的问题，隔离级别定义了并发事务间的相互影响程度；结果：不同的隔离级别应用于不同场景，常用RR和RC；实现：基于MVCC和锁实现；

原创 车载T-BOX

介绍  T-BOX（Telematics BOX），中文名叫做车载通信终端，相当于家庭上网的喵。对于车辆内部，T-BOX与车载CAN总线相连，可以将车辆的信息（车速、位置、油量、电量等），传送到手机/PC端，同时接受手机端等控制指令，对车辆进行控制，如下如所示：...

原创 Jackson常用注解

属性设置@JsonProperty  作用：作用在属性上，用于将JSON数据中的key与POJO对象中的key进行关联，也可以理解为设置属性别名；@JsonProperty("userName")private String name;@JsonIgnore  作用：作用在属性上，忽略某个属性；@JsonIgnoreprivate String name;@JsonForma...

原创 Content type 'application/json;charset=UTF-8' not supported

基础  SpringBoot接受到http请求后，会根据content-type来判断请求的数据格式，进而利用HttpMessageConverter将数据解析成特定的类型。对应JSON格式的数据，SpringBoot默认使用jackson进行数据的序列化/反序列化;可能原因原因1：缺少jackson相关的jar包<dependency> <groupId&gt...

原创 @RequestMapping参数解析

作用  将Http请求映射到具体的方法上;参数path/value：请求需要匹配的URL路径；method：请求需要匹配的方法；headers：请求头中需要包含的字段；consumes：请求的Content-Type需要匹配的范围；produces：返回值的数据格式及编码；...

原创 前端Long型数据精度丢失问题

现象  后端返回long型数据，但是前端展示时数据不一致。比如，后端返回的数据是1475797674679549851，但前端显示出来却成了1475797674679550000，后面几位全变成了0，精度丢失了。原因  Java long类型的的数字超出了Javascript的处理范围；解决办法  后端将long类型数据转为字符串返回给前端；实操全局更改spring.jackson...

原创 RPC接口设计总结

设计总结  对于RPC接口，设计之初就应该要考虑到接口的通用性、可扩展性、兼容性，以方便后期的修改和升级。设计总结入参入参校验  对外提供的开放接口，不管是 RPC/API/HTTP 接口都需要进行入参校验。实践中，可以利用hibernate-validator，在入参上通过注解的形式增加限制说明，校验时直接利用validator进行校验。//POM依赖<dependency&...

原创 软件项目管理（软件工程之美总结）

如何项目管理？  要管理好一个项目，关键是要管理好项目中的人和事。  项目中的人包括客户和项目成员。对客户的管理，本质是管理好客户的期望值，即软件质量、时间、成本和范围四个因素间的平衡，”金三角“理论可以帮助我们权衡取舍；对项目成员的管理，要做到”法治“，依靠流程规范管理项目成员，单纯的靠项目经理管理，容易出现分歧和瓶颈；  对事的管理即对软件开发过程的管理，首先选择好开发模型，然后制定项目...

原创 线上问题排查思路总览

原创 查看进程网络流量工具nethogs

介绍  按照进程维度查看网络收发流量；安装yum -y install nethogs使用查看所有网卡流量  命令：nethogs查看指定网卡流量  命令：nethogs eth1

原创 缓存查看利器hcache

简介  hcache是一款查看buff/cache的工具，可以查看进程的缓存占用情况，以及占用操作系统缓存最多的N的文件；安装wget https://silenceshell-1255345740.cos.ap-shanghai.myqcloud.com/hcachechmod +x hcachemv hcache /usr/local/bin/使用查看使用缓存最多的3个文件$...

原创 Linux基础之网络包收发流程

网络包的接收流程网络数据包（Frame）到达网卡，按照FIFO顺序存入网卡的接受队列；网卡通过DMA方式将接受队列的数据拷贝到内核缓冲区sk_buffer；当数据拷贝完成后，网卡通过硬件中断（IRQ）通知CPU有新的网络数据到来，CPU执行驱动程序（NIC Driver）的处理逻辑：3.1 禁用网卡的中断。这样做的目的是避免CPU被频繁的中断，当网卡接收到新的数据时直接写内存就可以了，...

原创 Linux基础之文件系统

什么是文件系统？  文件系统是操作系统对存储设备上文件一种管理机制，不同的管理机制形成了不同的文件系统；文件系统划分  按IO栈的层级来分，可以分为VFS和具体文件系统两层。VFS屏蔽不同的文件系统，向上提供统一的访问接口，具体的文件系统则为具体的文件系统实现，比如ext4、overlayfs等；  按存储介质的不同，文件系统可以分为三类：基于磁盘的文件系统，常见的有Ext4、XFS、...

转载 Linux零拷贝之sendfile/splice

  sendfile/splice实现了真正意义上的零拷贝：CPU完全不需要参与数据的拷贝，应用层Java NIO为开发人员提供了FileChannel.transferFrom()/transferTo()方法使用零拷贝。sendfile传输原理用户进程通过 sendfile() 函数向内核（kernel）发起系统调用，上下文从用户态（user space）切换为内核态（kernel s...

原创 Linux基础之IO栈

I/O栈  Linux 存储系统的 I/O 栈，由上到下分为三个层次，分别是文件系统层、通用块层和设备层。文件系统层，包括虚拟文件系统VFS和其他各种文件系统的具体实现。VFS作用就是屏蔽不同的文件系统，为上层提供一套标准的文件访问接口；通用块层，包括块设备 I/O 队列和 I/O 调度器。Block Layer作用是屏蔽底层异构设备，向上提供统一的款设备访问接口；还可以优化调度I/O请求...

原创 Linux基础之Swap

Swap机制  当物理内存不足时，Linux系统会释放出部分不常用的内存，临时保存到Swap空间（磁盘空间）中， 等应用程序需要这些内存时再从Swap分区中恢复保存的数据到内存中；  Swap机制只是内存回收策略的一种，内存不足时并不是只能使用swap机制；Swap大小查看free -m（静态）top（动态）sar -r -S 1（动态）内存回收机制  当物理内存不足时，L...

原创 Linux基础之Buffer/Cache

作用：  Buffer Cache和Page Cache都用来提升IO读写性能，大致原理如下：读性能： 通过预读提前加载数据，以及缓存频繁访问数据，减少I/O次数，提升读性能；写性能： 对上层的应用程序直接写入Page/Buffer即可返回，不用等待数据真正落盘；对下层的磁盘，由pdflush内核线程一次性地将多个写请求数据刷新到磁盘，减少I/O次数，提升写性能；区别  Buffe...

原创 Linux基础之内存

物理内存和虚拟内存定义  物理内存： 物理内存条提供的的内存空间，真正存储数据的地方；  虚拟内存： 每个进程的逻辑内存，特点是独立、连续，只是逻辑上存在，并不能真正存储数据；内存映射  因为所有进程的虚拟内存加起来会远超物理内存，所以操作系统只会给进程真正使用的虚拟内存分配物理内存，通过页表维护进程的虚拟内与与物理内存之间的映射关系，每个页表都有一个单独的页表，如下图所示：虚拟内存...

原创 Linux基础之CPU使用率

定义  CPU使用率是指某个任务(进程/线程/中断程序)在一定时间内占用CPU的时间比例；查看CPU使用率CPU维度  mpstat命令：查看所有或某个CPU使用率；（第一行的all表示所有CPU的平均使用率）[root@stress ~]# mpstat -P ALLLinux 3.10.0-514.16.1.el7.x86_64 (stress) 11/22/2019 _x86...