Jinqq's Home

开始

在markdown里插入的图片是默认保存在本地的，这样发布到线上之后肯定是无法看到的，因此我们需要借助图床来存储这些图片，本章将会讲如何购买oss，如何使用，以及typora的快速配置。

这一章其实与网页的搭建没什么直接关系，可以先暂时跳过。

本章特别鸣谢：lollipop

一 购买和配置OSS（对象存储服务）

为什么要用到OSS

Markdown 是一种轻量级的标记语言，常用于撰写博客文章、文档、论坛帖子等。在 Markdown 中插入图片时，通常需要用图片的 URL 来链接和显示图片。如果将图片直接存储在本地，博客更新、迁移或备份时可能会出现问题，因此我们常常将图片存储到图床中，然后markdown中插入这些图片的链接，就可以在任何地方都能看到这些图片了。

那么如何获得一个图床？OSS（对象存储服务） 可以作为图床的后端存储服务，提供图片存储、管理和分发功能。将图片存储到 OSS 中，可以利用 OSS 提供的高性能、高可靠性、低延迟的存储和访问能力，同时结合CDN 加速，确保全球用户快速访问图像资源。OSS 作为图床的后端存储，不仅可以支持图片的上传和存储，还可以根据需求提供各种功能，如图片处理、自动缩放、格式转换等。

一般好的OSS都是收费的，当然也有免费的OSS，但效果不好，我选择阿里云OSS。

简而言之：希望markdown中的图片可以在任何地方浏览 —-> 用图床存图片 —->购买OSS当图床

开始

前面讲到了Hexo的安装和基本使用，但是此时我们还是只能在本地预览网页，如何讲网页部署到线上去，让所有人都能看到呢？这里我们就将要借助gitlab pages的静态代码托管功能了。当然也有很多其他方案（详见第六章），但是gitlab pages是免费的，同时配置起来也比较简单。

本篇文章将主要讲搭建个人网页的第二步，包括gitlab基础，创建gitlab项目和gitlab pages部署。

一 Gitlab

GitLab 是一个基于 Git 的 DevOps 平台，集代码管理、持续集成/持续部署（CI/CD）、项目管理和版本控制于一体，为开发团队提供了从代码开发到部署的完整工具链。它支持私有仓库和公有仓库，提供了灵活的权限管理、代码评审功能以及高效的协作工具，适合团队协作开发。此外，GitLab 还具备强大的自动化能力和自托管选项，可以帮助团队提高开发效率并简化交付流程，是现代软件开发中的一站式解决方案。

Gitlab可以看作是另一个Github。

首先，我们需要有一个gitlab账号，访问这里 https://gitlab.com注册和登录。

记得在设置里将你的ssh公钥添加进去，具体操作可以参考gitlab添加SSH密钥——查看本地密钥 & 生成ssh密钥-CSDN博客。

开始

本篇文章主要讲搭建个人网页的第一步，包括安装hexo、掌握hexo的基本指令，以及如何使用hexo写博客。

前面还有零，建议阅读那一篇后再开始本篇。

一 安装Hexo

Hexo 是一个基于 Node.js 的快速、简洁且强大的静态博客框架，专为博客创作者设计。它支持使用 Markdown 撰写文章，生成静态文件，并通过简单的命令快速部署到各种平台（如 GitHub Pages、GitLab Pages 等）。Hexo 拥有丰富的插件和主题生态，用户可以轻松扩展功能或切换风格，同时生成速度极快，非常适合追求高效与可定制性的个人博客搭建者。

首先，创建一个空文件夹，取个名字，例如pentabin，接下来我们的命令和代码都在这里面。

然后在该文件夹中打开命令行，使用npm命令安装Hexo，输入：

1

npm install -g hexo-cli

安装完成后初始化博客：

1

hexo init blog

开始

这系列文章主要讲讲如何从零开始搭建个人网页，其实也就是本网站是如何被搭建起来的，当然作者也是这几天从零开始一点点尝试的，所以有很多地方可能还不成熟或者有问题，请谅解。

本文是一个开始，主要介绍下我们需要用到哪些技术和工具。

首先，你在开始之前，应当已经了解以下知识：

• **Node.js 和 NPM：**Node.js 是一个 JavaScript 运行环境，NPM 是其包管理器。Hexo 的运行和插件安装都依赖于 Node.js 和 NPM。
• **Git：**Git 是一个分布式版本控制系统，用于管理代码和项目的变更。搭建网站时，Git 可以帮助我们在本地开发后将代码推送到远程仓库（如 GitLab）。
• **Github或Gitlab：**GitHub 和 GitLab 是两款广泛使用的代码托管和协作平台，帮助开发者管理项目、版本控制和团队协作。如果你比较了解Github，那Gitlab对你而言也会很熟悉。
• **Markdown：**Markdown 是一种轻量级的标记语言，使用简单的语法即可快速编写格式化的文本。这里我们所有的博客其实都是一份份Markdown文件（简称md），因此你需要掌握基本的Markdown语法。

此外，本系列文章中的教程大多基于我的配置编写，文中提到的许多内容需要根据你的实际情况进行调整。我使用的是 Windows 11，如果你使用的是 Linux 或 macOS，有些地方也需要进行相应的调整。

Feed流

关注推送也叫Feed流，通过无限下拉刷新获取新的信息。

常见两种模式：

Feed流的实现方案

拉模式（读扩散）

消息先发布到发件箱，收件箱一开始为空，关注者每次读取时拉取所有消息，然后按时间戳排序。

优点：节省内存空间，收件箱读取完后可以清空

缺点：每次读取需要重新拉消息并排序，耗时较久。

推模式（写扩散）

消息直接发送到每个关注者的收件箱，可以直接读取。

优点：不需要临时拉取，延迟低。

缺点：内存占用高，每个消息要写多份。

推拉结合模式（读写混合）

对于大V，采用拉模式，消息先发件箱，等待拉取。对于普通人，采用推模式，消息直接推到关注者的收件箱中。

对于活跃粉丝，采用推模式，所有人的消息（包括大V）都会直接发到其收件箱中。而对于普通粉丝，只有读取时才会去拉取消息。

Feed流的分页问题

Feed流中的数据会不断更新，所以数据的角标也在变化，因此不能采用传统的分页模式。

Feed流的滚动分页

为了实现滚动分页效果，使用redis中的sorted set数据结构来存储消息和时间戳。

使用命令 ZREVRANGEBYSCORE key max min WITHSCORES LIMIT offset count

max：当前时间戳 | 上一次查询的最小时间戳

min：0

offset：0 | 上一次查询中，与最小值一样的元素个数

count：3

Redis消息队列

消息队列（Message Queue），存放消息的队列，最简单的模型包括3个角色：

• 消息队列：存储和管理消息，也成为消息代理（Message Broker）
• 生产者：发送消息到消息队列
• 消费者：从消息队列获取消息并处理消息

Redis提供了三种不同的方式来实现消息队列：

• list结构：基于List结构模拟消息队列
• PubSub：基本的点对点消息模型
• Stream：比较完善的消息队列模型

基于List结构模拟消息队列

Redis的list结构是一个双向链表，可以模拟队列效果。不过要注意的是，当队列没有消息时，RPOP或LPOP操作 会返回null，为达到阻塞效果，应该使用BRPOP或BLPOP。

优点：

• 利用Redis存储，不受限于JVM内存上限。
• 基于Redis的持久化机制，数据安全性有保证。
• 可以满足消息有序性。

缺点：

• 无法避免消息丢失。BRPOP后，如果服务宕机没有处理消息，那么消息就会丢失。
• 只支持单消费者 。

基于PubSub的消息队列

PubSub是Redis2.0版本引入的消息传递模型。消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有订阅者都能收到相关信息。

• SUBSCRIBE channel [channel]：订阅一个或多个频道
• PUBLISH channel msg：向一个频道发送消息
• PSUBSCRIBE pattern[pattern]：订阅与pattern格式匹配的所有频道

优点：

• 采用发布订阅模型，支持多生产、多消费。

缺点：

• 不支持数据持久化。
• 无法避免消息丢失。发布消息如果没人订阅，则消息丢失。
• 消息堆积有上限，超出时数据丢失。

基于Stream的消息队列

Stream

Stream是Redis5.0引入的一种新数据类型，可以实现一个功能非常完善的消息队列。

在业务中，可以循环的调用XREAD阻塞方式来查询最新消息，从而实现持续监听队列的效果。

1
2
3
4
5
6
7

while (true){
	Object msg = redis.execute("XREAD COUNT 1 BLOCK 2000 STREAMS users $")
	if (msg == null){
		continue;
	}
	handleMessage(msg);
}

但是当我们指定其实ID为$时，代表读取最新的消息，如果我们处理一条消息的过程中，又有超过1条以上的消息到达队列，则下次获取时也只能获取到最新的一条，会出现漏读消息的问题。

XREAD特点：

• 消息可回溯
• 一个消息可以被多个消费者读取
• 可以阻塞读取
• 有消息漏读的风险

消费者组

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

while (true){
	// 尝试监听队列，使用阻塞模式，最长等待2000ms
	Object msg = redis.call("XREADGROUP GROUP g1 c1 COUNT 1 BLOCK 2000 STREAMS s1 >");
	if (msg==null){ // null说明没有消息，继续下一次 
		continue;
	}
	try{
		handleMessage(msg);
	} catch(Exception e){
		while (true){
			Object msg = redis.call("XREADGROUP GROUP g1 c1 COUNT 1 STERAMS s1 0");
			if (msg == null){	// null说明没有异常消息，所有消息都已确认，结束循环
				break;
			}
			try{
				//说明有异常消息，再次处理
				handleMessage(msg);
			} catch(Exception e){
				// 再次出现异常，记录日志，继续循环
				continue;
			}
		}
	}
}

XREADGROUP特点：

• 消息可回溯
• 可以多消费者争抢消息，加快消费速度
• 可以阻塞读取
• 没有消息漏洞的风险
• 有消息确认机制，保证消息至少被消费一次

为何需要异步秒杀

该图是秒杀业务的部署图，按照顺序进行每个步骤，耗时为所有步骤之和，其中一些业务还需要访问mysql，导致整个流程缓慢，效率低。因此需要用到异步秒杀。

一 一人一单的并发安全问题

原来使用synchronized悲观锁用户id来保证一人一单，如下图：

一 超卖问题

缓存击穿

缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问在瞬间给数据库带来巨大的冲击。