熟悉 HTTP 协议的同学都知道，ORS 是 HTTP 协议中的一种安全策略，全称是 Cross-origin resource sharing，中文名称是跨域资源共享，是一种让受限资源能够被其他域名的页面访问的一种机制。

下图描述了 CORS 机制。

本文来自我最近正在学习的课程，极客时间郭东白的专栏文章。这篇文章让我在架构悟道上有所觉悟，分享给你，希望对你有所启发，部分内容我作了精简，内容如下。

人类的各种活动都要遵循事物的客观生命周期。不论是农业社会种田打渔，还是资本社会投资创业，行动太早或太晚，都会颗粒无收。技术也一样，也有自己的生命周期。而我们作为架构师，如果看不清技术的生命周期，那么所设计的架构就没法儿向更有生命力的新技术借力，自己的职业生涯也会受限。

在架构设计的过程中，架构师会有一个相对确定的商业和技术选择空间。在这个选择的空间内，架构师做技术选型的时候，必须要考虑到所依赖的商业和技术模块的生命周期。这个时候，我们就需要看准技术趋势，选择已经有规模优势或者是即将有规模优势的技术，而不是选择接近衰老期的技术。

但是啊，有的人能够看准一个技术的生命周期， 而有些人却做不到。为什么？

这里总结了23种设计模式的结构图及定义，样例代码在 Github：studeyang/design-pattern。

一、创建型模式

1.1 简单工厂模式

这里记录的是学习分享内容，文章维护在 Github：studeyang/leanrning-share。

优化查询语句的性能是 MySQL 数据库管理中的一个重要方面。在优化查询性能时，选择正确的索引对于减少查询的响应时间和提高系统性能至关重要。但是，如何确定 MySQL 的索引选择策略？MySQL 的优化器是如何选择索引的？

在这篇《索引失效了？看看这几个常见的情况！》文章中，我们介绍了索引区分度不高可能会导致索引失效，而这里的“不高”并没有具体量化，实际上 MySQL 会对执行计划进行成本估算，选择成本最低的方案来执行。具体我们还是通过一个案例来说明。

案例

还是以人物表为例，我们来看一下优化器是怎么选择索引的。

建表语句如下：

1
2
3
4
5
6
7
8
9
10
11

CREATE TABLE `person` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(64) NOT NULL,
  `score` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_name_score` (`name`,`score`) USING BTREE,
  KEY `idx_age` (`age`) USING BTREE,
  KEY `idx_create_time` (`create_time`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4;

然后插入 10 万条数据：

1
2
3
4
5
6
7
8
9
10

create PROCEDURE `insert_person`()
begin
    declare c_id integer default 3;
    while c_id <= 100000 do
	    insert into person values(c_id, concat('name',c_id), c_id + 100, c_id + 10, date_sub(NOW(), interval c_id second));
	    -- 需要注意，因为使用的是now()，所以对于后续的例子，使用文中的SQL你需要自己调整条件，否则可能看不到文中的效果
	    set c_id = c_id + 1;
    end while;
end;
CALL insert_person();

索引是 MySQL 数据库中优化查询性能的重要工具，通过对查询条件和表数据的索引，MySQL可以快速定位数据，提高查询效率。但是，在实际的数据库开发和维护中，我们经常会遇到一些情况，导致索引失效，从而使得查询变得非常缓慢，甚至无法使用索引来优化查询，这会严重影响系统的性能。那么，是什么原因导致了索引失效呢？

常见的情况有：

• 索引中断
• 数据类型不匹配
• 查询条件使用函数操作
• 前模糊查询
• OR 查询
• 建立索引时使用函数
• 索引区分度不高

下面我通过实际的例子来具体说说。假设现在我们有一张人物表，建表语句如下：

1
2
3
4
5
6
7
8

CREATE TABLE `person` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(64) NOT NULL,
  `score` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4;

简介：传统的消息队列对业务方提出了更高的要求，我们期望提供的是一种以业务为重心的，面向服务的解决方案。

这里记录的是学习分享内容，文章维护在 Github：studeyang/leanrning-share。

我们在上次分享中聊到了领域驱动设计和微服务，在 DDD 中有一个术语叫做领域事件，例如订单模型中的订单已创建、商品已发货。领域事件会触发下一步的业务操作，如果领域事件发生在微服务内，可以通过观察者模式很容易实现消息监听并处理。

如果发生在微服务之间，则需引入事件总线或者消息中间件。

这里记录的是学习分享内容，文章维护在 Github：studeyang/leanrning-share。

如何理解领域驱动设计？

随着微服务的兴起，你一定听说过领域驱动设计 DDD（domain-driven design），但是如果把它当成一个术语来看，似乎有点抽象。这到底是个什么玩意？

别急，你肯定还听说过测试驱动开发（TDD, Test-driven development）吧？

这是个什么概念呢？就是说开发的过程中要测试先行，倡导先写测试程序，然后编码实现。开发是目的，测试是辅助，所以叫做测试-驱动-开发，我们应该把它拆成 3 个术语来理解。

所以，对于领域驱动设计，设计是目的，领域才是辅助。想要设计一个软件，但是由于业务太过复杂，设计过程难以进行。这时，使用领域的思想来辅助设计。

本文摘要：浅谈应用架构、业务架构、技术架构。

什么是架构？

说到架构，这个概念没有很清晰的范围划分，也没有一个标准的定义，每个人的理解可能都不一样。

架构在百度百科中是这样定义的：架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

我们可以理解为：架构设计的主要目的是为了解决软件系统复杂度带来的问题。

卡内基·梅隆大学的玛丽·肖（Mary Shaw）和戴维·加兰（David Garlan）在文章《软件架构介绍》（An Introduction to Software Architecture）中写到：

“When systems are constructed from many components, the organization of the overall system-the software architecture-presents a new set of design problems.”

译：随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。

软件架构的核心价值，即是控制系统的复杂性，将核心业务逻辑和技术细节的分离与解耦。

架构师的职责是努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构；能够进行系统分解形成整体架构，能够正确的技术选型，能够制定技术规格说明并有效推动实施落地。

这里记录的是学习分享的内容，文章维护在 Github：studeyang/leanrning-share。

回顾

在文章《Redis 的 String 类型，原来这么占内存》中，我们学习了 SDS 的底层结构，发现 SDS 存储了很多的元数据，再加上全局哈希表的实现，使得 Redis String 类型在内存占用方面并不理想。

然后在文章《学习分享（第1期）之Redis：巧用Hash类型节省内存》中，我们学习了另一种节省内存的方案，使用 ziplist 结构的 Hash 类型，内存占用减少了一半，效果显著。

虽然我们在使用 String 类型后，占用了较多内存，但其实 Redis 是对 SDS 做了节省内存设计的。除此之外，Redis 在其他方面也都考虑了内存开销，今天我们就从源码层面来看看都做了哪些节省内存的设计。

文中代码版本为 6.2.4。

一、redisObject 的位域定义法

我们知道，redisObject 是底层数据结构如 SDS, ziplist 的封装，因此，redisObject 如果能做优化，最终也能带来节省内存的用户体验。在源码 server.h 中定义了 redisObject 的结构体，如下面代码所示：

1
2
3
4
5
6
7
8
9

#define LRU_BITS 24

typedef struct redisObject {
    unsigned type:4;//对象类型（4位=0.5字节）
    unsigned encoding:4;//编码（4位=0.5字节）
    unsigned lru:LRU_BITS;//记录对象最后一次被应用程序访问的时间（24位=3字节）
    int refcount;//引用计数。等于0时表示可以被垃圾回收（32位=4字节）
    void *ptr;//指向底层实际的数据存储结构，如：sds等(8字节)
} robj;

type, encoding, lru, refcount 都是 redisObject 的元数据，redisObject 的结构如下图所示。

开篇

之前的分享内容都是相对零散的知识点，不成体系。以后的每周分享，我会尽量将每篇文章串连起来，于是我决定做一个专栏，名字就叫《学习分享》。这是该系列的第一篇。

《学习分享》内容大多来自我平时学习过程中的笔记，笔记仓库在 Github：studeyang/technotes。其中我认为有深度、对工作有帮助的内容，就会以文章的形式发表在该专栏，内容会首发在我的公众号、掘金和今日头条，也会维护在 Github：studeyang/leanrning-share。

回顾

上篇文章《Redis 的 String 类型，原来这么占内存》中，我们使用 String 类型存储了图片 ID 和图片存储对象 ID，结果发现两个 Long 类型的 ID 竟然占了 68 字节内存。具体验证过程，我还是贴一下方便你回顾。

1、查看 Redis 的初始内存使用情况。

1
2
3

127.0.0.1:6379> info memory
# Memory
used_memory:871840

2、接着插入 10 条数据。

1
2
3
4
5
6
7
8
9
10

10.118.32.170:0> set 1101000060 3302000080
10.118.32.170:0> set 1101000061 3302000081
10.118.32.170:0> set 1101000062 3302000082
10.118.32.170:0> set 1101000063 3302000083
10.118.32.170:0> set 1101000064 3302000084
10.118.32.170:0> set 1101000065 3302000085
10.118.32.170:0> set 1101000066 3302000086
10.118.32.170:0> set 1101000067 3302000087
10.118.32.170:0> set 1101000068 3302000088
10.118.32.170:0> set 1101000069 3302000089

3、再次查看内存。

1
2
3

127.0.0.1:6379> info memory
# Memory
used_memory:872528

可以看到，存储 10 个图片，内存使用了 688 个字节。一个图片 ID 和图片存储对象 ID 的记录平均用了 68 字节。

这是上次我们讲述的场景。

并且还留下了一道思考题：既然 String 类型这么占内存，那么你有好的方案来节省内存吗？

今天呢，我们就来具体谈一谈。