Java日知录

电商当项目经验已经非常普遍了，不管你是包装的还是真实的，起码要能讲清楚电商中常见的问题，比如库存的操作怎么防止商品被超卖。

在日常开发中有很多地方都有类似扣减库存的操作，比如电商系统中的商品库存，抽奖系统中的奖品库存等。

解决方案

常见的解决方案有以下三种：

1. 使用 mysql 数据库，使用一个字段来存储库存，每次扣减库存去更新这个字段。
2. 还是使用数据库，但是将库存分层多份存到多条记录里面，扣减库存的时候路由一下，这样子增大了并发量，但是还是避免不了大量的去访问数据库来更新库存。
3. 将库存放到 redis 使用 redis 的 incrby 特性来扣减库存。

计算机学什么

抽象模型

庄子说过吾生有崖，知无涯。以有限的生命去学习无尽的知识是很愚蠢的。所以，学习的终极目标一定不是知识本身，因为知识是表象的、不稳定、会过时。那么我们应该学什么，什么东西才是永恒的？也许我们会有很多见解，比如学习哲学，或者叫哲科；或者学习方法论；或者学习抽象模型等等…

这些抽象模型的完美体现就是我们经常看到的数学公式，公式好比万能工具，通过它我们可以知道宇宙和自然是如何规律运转的。

现实中，我们会发现各个学科都有自己的抽象模型，这些模型好比天上的繁星，有相似的，更多的是各不相同。所以，认知结构的拓展其实就是对模型边界的拓展，我们拥有的模型越多，我们的认知越丰富。

对于计算机来说，什么是那个不变的宗呢？

大家好，我是飘渺。

今天我们通过一篇文章来认识一下常见消息队列RabbitMQ、RocketMQ、Kafka。

RabbitMQ

RabbitMQ各组件的功能

• Broker ：一个RabbitMQ实例就是一个Broker
• Virtual Host ：虚拟主机。相当于MySQL的DataBase，一个Broker上可以存在多个vhost，vhost之间相互隔离。每个vhost都拥有自己的队列、交换机、绑定和权限机制。vhost必须在连接时指定，默认的vhost是/。
• Exchange ：交换机，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
• Queue ：消息队列，用来保存消息直到发送给消费者。它是消息的容器。一个消息可投入一个或多个队列。
• Banding ：绑定关系，用于消息队列和交换机之间的关联。通过路由键（Routing Key）将交换机和消息队列关联起来。
• Channel ：管道，一条双向数据流通道。不管是发布消息、订阅队列还是接收消息，这些动作都是通过管道完成。因为对于操作系统来说，建立和销毁TCP都是非常昂贵的开销，所以引入了管道的概念，以复用一条TCP连接。
• Connection ：生产者/消费者 与broker之间的TCP连接。
• Publisher ：消息的生产者。
• Consumer ：消息的消费者。
• Message ：消息，它是由消息头和消息体组成。消息头则包括Routing-Key、Priority（优先级）等。

在架构设计中，要实现业务上的复用，一个比较可行的做法是，把各个基础业务封装成共享服务，供上层所有应用调用。所以今天，我就来和你聊一聊，如何
从头开始，落地这样一个典型的共享服务。

我们知道，落地一个微服务其实并不困难，但要实现一个能够高度复用的共享服务并不容易，在落地过程中，经常会有一系列的问题困扰着我们。

• 我们事先对服务的边界没有进行很好的划分，结果在落地的过程中，大家反复争论具体功能的归属。

• 由于对业务的了解不够深入，我们要么设计不足，导致同一个服务有很多版本；要么服务过度设计，实现了一堆永远用不上的功能。

大家好，我是飘渺。

分布式数据库架构下，索引的设计也需要做调整，否则无法充分发挥分布式架构线性可扩展的优势。今天我们就来聊聊 “在分布式数据库架构下，如何正确的设计索引？”。

主键选择

对主键来说，要保证在所有分片中都唯一，它本质上就是一个全局唯一的索引。如果用大部分同学喜欢的自增作为主键，就会发现存在很大的问题。

因为自增并不能在插入前就获得值，而是要通过填 NULL 值，然后再通过函数 last_insert_id()获得自增的值。所以，如果在每个分片上通过自增去实现主键，可能会出现同样的自增值存在于不同的分片上。

大家好，我是飘渺。

上次面试官问了个问题：应用上线后Cpu使用率飙升如何排查？

其实这是个很常见的问题，也非常简单，那既然如此我为什么还要写呢？因为上次回答的时候我忘记将线程PID转换成16进制的命令了。

所以我决定再重温一遍这个问题，当然贴心的我还给大家准备好了测试代码，大家可以实际操作一下，这样下次就不会忘记了。

大家好，我是飘渺。

分布式数据库架构下，索引的设计也需要做调整，否则无法充分发挥分布式架构线性可扩展的优势。今天我们就来聊聊 “在分布式数据库架构下，如何正确的设计索引？”。

主键选择

对主键来说，要保证在所有分片中都唯一，它本质上就是一个全局唯一的索引。如果用大部分同学喜欢的自增作为主键，就会发现存在很大的问题。

因为自增并不能在插入前就获得值，而是要通过填 NULL 值，然后再通过函数 last_insert_id()获得自增的值。所以，如果在每个分片上通过自增去实现主键，可能会出现同样的自增值存在于不同的分片上。

比如，对于电商的订单表 orders，其表结构如下（分片键是o_custkey，表的主键是o_orderkey）：

大家好，我是飘渺。

我负责的系统到2021年初完成了功能上的建设，开始进入到推广阶段。随着推广的逐步深入，收到了很多好评的同时也收到了很多对性能的吐槽。刚刚收到吐槽的时候，我们的心情是这样的：

当越来越多对性能的吐槽反馈到我们这里的时候，我们意识到，接口性能的问题的优先级必须提高了。然后我们就跟踪了1周的接口性能监控，这个时候我们的心情是这样的：

大家好，我是飘渺。听多了架构优化，数据库优化，今天我们来聊聊服务器优化。

我们开发的软件服务需要在服务器上运行，所以服务器性能代表了软件的性能上限，因此服务器性能调优是个十分重要的环节，然而大部分同学对服务器性能调优关注的较少，今天从3个部分对服务器性能调优进行介绍，分别是：服务器配置选择，服务器负载分析，服务器内核参数调优。

服务器配置选择

服务器一般是由CPU、内存、磁盘和网卡组成，因此选择服务器配置就是选择CPU核数、内存大小、磁盘大小及类型、网络带宽。但是，服务器配置的选择是很难标准化的，也就是说很难推断出“一台需要达到1000TPS的后端服务器”的配置应该是什么样的。因为软件的最终运行性能与软件的实现方式是紧密相关的，即使是同一个后端应用程序中的两个接口，由于具体功能的差别，性能也会有所差别。

大家好，我是飘渺。

粉丝群里一直有人在讨论DDD，看来大家对DDD还是比较感兴趣的。所以今天我们来实践一下。同时为了证明该文没有注水，列一下当时的学习资料：

• 小米内部 DDD 系列分享；
• 小米内部 DDD 脚手架；
• 小米内部授权认证项目（应用 DDD）；
• 极客时间欧创新的《 DDD 实战课》；
• 掘金“柏炎”的 DDD 系列文档和 DDD Demo；
• 美团技术团队、阿里云开发社区、网上博客等。

不 BB，直接上思维导图！