这是我gRPC系列的第二篇， 上一篇是 gRPC系列：（1）Protobuf 简要介绍 | Finley’s Blog 前言 这篇文章将开发一个简单的测试项目，使用 Golang 作为服务器， 前端将使用三种不同的技术：Golang 的 cli 项目、Flutter 的 Desktop 项目、Vue (gRPC-Web) 这篇文章将在简要介绍gRPC的基础上，开发一个 Golang 的gRPC 服务器，并且使用 gRPCurl 和 Apifox 进行测试。 Proto 设计 编写 proto 文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 syntax = "proto3"; package user; option go_package = "/api"; import "google/protobuf/empty....

这是 gRPC 系列博客的第一篇，本篇将简要介绍 Protobuf 这一gRPC定义语言。 Protocol Buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data. (笔者译：Protocol Buffers 是一个语言中性的、平台中性的拓展性序列化结构数据的机制) Protocol buffers are a combination of the definition language (created in .proto files), the code that the proto compiler generates to interface with data, language-specific runtime libraries, and the serialization format for data that is written to a file (or sent across a network connection). (笔者译：Protocal Buffers 是下列功能的集合：定义语言（通过.proto文件)、生成接口和数据代码的 proto 编译器，特定语言的运行库、以及存储到一个文件（或通过网络传输）的序列化格式...

引言 程序的并发实现方式，常见的无非如题所述的三种： 线程、进程和协程。本文将总结三者的区别，以及在 python 和 golang 等语言中的实际应用。 并发、并行、异步、同步 并发 (Concurrency)，是指在同一段时间内执行多个程序 并行（Parallelism），是指在同一刻有多个程序在同时执行 并发可以理解为两个（或多个）程序表现上能同时进行。 而真正意义上的同时，对于单核CPU，真正意义上的并行（在某一个时刻，同时运行多个程序）并不存在。 因此从直白的说，并发是一种程序的调度技术，使CPU的空闲时间降低，而大大提高效率。 CPU 本身也有并发技术，如中断机制、流水 CPU、DMA等等，这并非是本文的重点。 异步（Asynchrony)，是指多个程序的运行并没有时间上的顺序关系 非阻塞（Non-blocking），是指程序的执行过程中不存在等待，是异步的实现 同步（Synchrony)，和异步相对，程序的运行有时间上的顺序，通常会有阻塞 阻塞 (Blocking)， 是指任务执行过程中的暂停或等待，通常是为了实现同步 在时序逻辑电路中也有同步和异步的概念，同步的时序逻辑电路通常引入一个统一的时钟信号。 并发安全 程序的并发需要考虑的一个问题就是并发安全。 对于一段数据，由于并发的存在，可能存在脏读的情况。 一般的解决方式是通过加锁的方式，产生一定程度上的阻塞，从而避免并发导致的数据冲突。 能避免由于并发而造成的数据冲突的数据结构称之为并发安全的（或是线程安全的） 线程 线程 (Thread) 是 CPU 调度的最小单位。也就是说子线程的执行先后顺序是由CPU决定调度的。 一个进程可以有多个线程。 Python 中多线程的实现 1 2 3 4 5 6 7 8 9 10 11 12 13 import threading def sub_program(name: str) -> None: for _ in range(5): print(f'Hello {name}') def main() -> None: threads = [threading....

引言 最近在研究 gRPC 的 TLS 通信， 是时候整理一下这几个相似概念了。 TLS Transport Layer Security 传输层安全协议 SSL Secure Sockets Layer 安全套接层 HTTPS HyperText Transfer Protocol Secure 超文本传输安全协议 SSH Secure SHell 安全外壳协议 TLS/SSL 网景公司（Netscape）在1994年推出首版网页浏览器－网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。 TLS 的前身是 SSL，因此在很多场合，两者是混用的（或者是直接称之为 TLS/SSL ) 公钥/私钥 背景知识：对称加密和非对称加密。 简单来说有三点： 对称加密只有一个密钥：也就是说通过密钥加密，也通过密钥解密 非对称加密有公钥和私钥：通过公钥加密的信息只能通过私钥解密；并且无法通过公钥得到私钥。 对称加密的效率要高于非对称加密 服务器端掌握公钥和私钥， 客户端掌握公钥（或者说是服务器向客户端发送公钥） 以下将描述两个场景： 场景1 通过 HTTPS 协议访问网站 客户端请求服务器 服务器返回公钥证书 客户端验证公钥证书是否合法 产生随机对称密钥，通过公钥加密后发送给服务器 服务器同私钥解密后，使用对称密钥进行对称加密通信 场景2 客户端访问访问服务器 客户端内携带公钥证书 客户端产生随机密钥，通过公钥发送给服务器 服务器通过私钥进行解密 使用密钥进行对称加密的通信 我想读者此时有几个问题： Q1: 为什么不能使用对称加密呢？ A: 客户端和服务端必须同时拥有密钥才能进行通信，那么在这个过程中理论上密码就会有泄漏的风险：想象一下，密钥一定是从服务端或者客户端生成的，需要将密钥传给另一端的过程中必然经过危险的网络环境。因此单纯的对称加密是不可行的。 Q2: 为什么不能全部使用非对称加密呢？ A：因为非对称加密的效率不如对称加密。通过安全的方式将对称加密密钥送到另一端，那么对称加密也是安全的。 HTTPS HTTPS 也就是使用TLS 的HTTP，也就是上一小节中提到的场景1的情况。...

中断 中断：Interrupt 是一种程序随机切换的方式 中断的典型应用： 实现CPU与外界信息交换的握手联络：实现CPU和外部设别的并行工作、提高CPU的效率 故障处理：硬件故障 实时处理 程序调度 软中断（程序自愿中断） 中断的分类： CPU 中断 软件中断 硬件中断 几个中断的概念 中断向量: 中断服务的入口 中断单级/多级：多个中断服务程序 开/关（清）中断：开中断(STI,Set Interrupt)就是允许响应中断请求，关中断(CLI, Clean Interrupt) 就是拒绝响应中断请求。 中断请求: IR(Interrupt Request): 请求进行中断，由外部设备、软件发出 中断响应: INTA(INTerrupt Accept): CPU 发出，可以进行中断。 中断返回：返回到进入中断程序之前的程序（继续之前的程序执行） 8259 芯片 Intel 8259芯片: 可编程中断控制器芯片 可以级联，单片支持8个中断向量设置 (本实验仪中只能使用一个, KK+ 连接 IR0, 且设置了ICW4 只接受 IR0) 和实验 3.2 没有中断的复杂模型机的区别： 更多的操作（至少包括 STI, CLI, IRET) 挂接 8259 芯片 注意： 8259 作为一个外部设备挂接在 IOY3 上 控制总线 INTA 与 8259 相连 当外部中断请求有效(IR)，CPU允许中断(EI, 也就是 经过了STI)，在一条指令执行完时，将响应中断。 CPU响应中断时会向 8259 发送 $\overline{INTA}$...

Typst Typst 是最近很火的一个试图取代 $\LaTeX$ 的写作引擎。 笔者经过一段时间的尝试后表示：十分推荐，但当下社区环境不佳。 当下的学习成本还是很高的。 以下是笔者认为的推荐的理由： 编译很快很好用: typst watch example.typ 就可以自动检测文件更新，增量编译，速度很快 可自定义程度很高: 可以操作很基础的组件（例如space, box等) 进行相当细致的样式调整 有分支、循环语句，有函数有变量，可以编写脚本。这其实是一把双刃剑，coder肯定很喜欢，但是对于非专业人士 可能这就是冗余功能甚至会造成一些困扰。 但是 typst 还是有一些缺点的： 首要的缺点就是当下typst社区环境很差 拿LaTeX来比较，安装 texlive-full 以后， 导包\documentclass{ctexart} 就可以直接生产一篇 排版相当优美的论文。但是 typst 需要自行编写排版格式（或者去github上找） 没有官方中文文档，如果要深入学习了解则需要啃英文文档。 语法复杂。 引用tree-sitter-typst 作者的说法： This language is soooo hard to parse… whitespace, parenthesizes for everything, and Unicode (笔者的翻译: 这个语言太tm难解析了……空格，全部都是括号，还有Unicode ) 实践 笔者写了一个功能不算很健全的模板（包括了浙江工业大学课设的模板） 参考了 https://github.com/werifu/HUST-typst-template 笔者的模板repo： https://github.com/zjutjh/zjut-report-typst 以后笔者应该也会经常维护这个仓库。并不只是局限于课设模板。 一些想法 对于较为成熟的LaTeX数学引擎是否可以把它的语法抄过来？ 毕竟很多人都熟悉了 LaTeX 的数学语法。

引言 为什么要用到这个奇怪的东西呢？ 原因是要写 cpp 的课程设计，题目是一个简单的用户管理系统。 但是可以在这个基础上拓展。 很多同学选择了老师推荐的 Qt 框架 但是 Qt 毕竟和我已有的知识相去甚远（而且也是古代的东西） 思来想去可以通过 grpc 框架生成 cpp server 代码（实际上还是参考了不少资料） GUI则通过现代化的 flutter 框架实现。 cpp引入grpc，据grpc github 官方 repo 中的说法，他们团队使用的构建工具就是 bazel 于是决定干脆学一下这个奇怪的东西。 为什么不学 cmake 呢？因为笔者认为cmake也是古代的技术，既然都要学，为什么不学新的技术？对于Qt也同理。 什么是 Bazel Bazel: Google 开发的与 make, maven 等类似的 开源的构建和测试工具。 使用 Bazel 的项目结构是很简单的 项目的根目录由 WORKSPACE 文件标识， 这个文件通过也担任 bazel 的项目设置的功能。 分支子目录则由 BUILD 文件标识。 需要注意的是上述的两个文件，都使用 Starlark Language Starlark Language 实际上是 Python 的一个方言，但是实际上不用管这么多。。 更多请参考：GitHub - bazelbuild/starlark: Starlark Language 也可以参考笔者的cpp课设项目：GitHub - FinleyGe/cpp-curriculum-design-employee: Cpp Curriculum Design: employee management...

Cache 高速缓冲存储器，是 解决 CPU 和主存之间 速度不匹配而采用的一项重要技术。 Cache 由高速的 SRAM 组成，其全部功能都由硬件实现。 Cache 除了 SRAM 外还需要逻辑控制。 若 Cache 在 cpu 外，则其逻辑控制一般与内存的逻辑控制合成， 成为主存/cache控制器。 若cache在CPU内，则由CPU提供它的控制逻辑。 Cache 的几个基本概念 以字为单位与CPU进行数据交换。 以块为单位与主存进行数据交换。 cache 中的数据以行为单位存储 一个字包含一个或若干个字节。 一个块有多个字组成，定长。 一个行的大小等于块的大小。 需要注意，cache 的行的大小通常是指 cache 中的数据部分。而地址存储在标记部分中。 当cpu读取一个字时，首先通过cache判断是否在cache中，如果是则cache命中，否则为cache缺失 由此引出 Cache 的性能指标： 命中率 cache的命中率 $$ h = \frac{N_{c}}{N_{c} + N_{m}} $$ $N_{c}$ cache完成的存取次数 $N_{m}$ 内存完成的存取次数 平均访问时间 $$ t_{a} = ht_{c} + (1-h)t_{m} $$ 其中： $t_{c}$ 为命中时 cache 的访问时间 $t_{m}$为未命中时主存的访问时间 访问效率: $$ e = \frac{t_{c}}{t_{a}} = \frac{1}{r+(1-r)h} $$ 地址变换 为了做到对CPU而言，cache的透明性。需要特定的地址变换方式。...

为什么要升级到3.1.1 3.1.1 似乎并非是一个正式的版本， 但是浙江工业大学的数据库原理课程使用此版本的 Opengauss， 在实验中，如果使用其下的版本将会遇到 with check option 未实现的问题 升级的解决方案 通过虚拟机安装 openEuler (正如我这篇博客) 即使是最新的22.03 LTS 版本，自动安装的也还是3.1.0 而手动更新想毕是繁琐的（笔者并未尝试） 于是决定在 enmotech-docker-opengauss 3.1.0的基础上进行修改，直接打包一个3.1.1版本的docker镜像。 目前笔者只打包了amd架构版本的镜像文件，已经上传到docker.io 以下为安装此版本的方式 安装笔者自己打包的3.1.1docker镜像的步骤 0. 确保docker已经安装并且运行 理论上docker是跨平台的优秀解决方案。 笔者在archlinux下使用没有障碍。 由于笔者精力有限，windows, mac 下的docker并未测试过 以下命令均在 archlinux 6.2.8 arch-1-1, ubuntu 20.03 下经过测试。 1. 停止原先3.1.0版本的运行 如果您正在使用3.1.0版本的镜像，请先停止其的运行（但是并不要删除） 1 sudo docker stop [your-container-name] [your-container-name]是你的opengauss3.1.0镜像的容器名称 如果忘记可以通过 1 sudo docker ps 查看 2. 安装docker镜像 1 sudo docker run --name [container-name] --privileged=true -p 5432:5432 -d -e GS_PASSWORD=[Pass@word] finleyge/opengauss:3.1.1 [container-name] 是容器的名称，可以随意填写 [Pass@word] 是 omm 的密码，需要大小写、数字、特殊字符四选三。 3....

数的表示 对于一个数字： 真值：书写表示的数值。 机器码：机器中实际的编码。 例如: 对于数字 10. 我们说10, 就是该数的真值。而 00001010 表示机器中以8位二进制表示的10 原码 最高位为符号位， 1 为 负，0为正。 其余数位则为真值的二进制表示。 实际上在计算机中不常见。 反码 就是在原码的基础上，对所有数位进行取反。 补码 补码的目的是为了在加减法计算中，可以通过相同的电路进行计算。 从原码转补码的方法有两种： 正数不变，负数除了符号以外都取反+1。 如果是正数，当然不用改变。如果是负数，则符号位不变，最低的1不变，中间的数位取反。 例如要对数$11001010$（原码）转换为补码。 若采用方法1 是负数，则除了第一位以外全部取反，得到$10110101$ $+1$得到 $10110110$ 采用方法2: 是负数，则第一位和最后一个1不变，中间的取反，得到$10110110$ 将补码转换为原码同样可以采用和上述一致的操作。 （换言之，补码是成对出现的，二者是互补的关系） 移码 也叫增码或偏置码。 从形式上将，移码是在补码基础上， 符号位与补码相反，其余部分相同。 移码是 IEEE 754 标准浮点数的阶码表示方法，其原因可以见后文。 例子 下面为几个上述机器码的实例， 都使用8位二进制数表示， 首位为符号位。 真值 原码 反码 补码 移码 10 00001010 11110101 00001010 10001010 -10 10001010 01110101 11110110 01110110 -128 无法表示 无法表示 10000000 00000000 -127 11111111 00000000 10000001 00000001 数据格式 存储一个数据需要考虑以下因素：...