软通智算
项目面time: 2024.12.18 筋斗云1. 项目情景介绍简要介绍项目的背景、目标、使用技术栈以及核心功能。 为什么项目中同时涉及到了Gin和Hertz两个框架？使用到了Hertz中的什么特性？项目本身是使用Gin开发的，后来进行了一次重构。因为学习到了Hertz，就使用了Hertz尝试进行重构。使用到了其中的中间件。 目前上线的话 上线使用的范围...
Operating Sys
Merry Christmas! operating sys 瞎记乱学 这里所记的是南京大学Jyy2024春 虚拟化前的笔记 部分理解的内容有遗漏 或者记在其他文档上了 存储相关内容TBD 有可能跑去学mit6.s081了 应用层面所有的程序本身只有数据，而在程序运行中只有数据的处理。程序本身是没有能力打开或关闭的 需要依赖于系统调用(system call) 在操作系统的上下文中，程序本身是由数据和代码组成的静态实体，它只有在被加载和执行时才会成为一个动态的进程。程序本身没有能力自行打开或关闭，而是依赖于操作系统提供的系统调用（system call）来执行这些操作。 所有的程序都可以理解为一个黑盒子 sandbox 所有的软件都只是设计了对应数据的IO 窗口 浏览器等页面也是同理 软件本身并不具备打开窗口的能力 而是各操作系统上提供了一个任务管理器 此任务管理器提供对应的api给各软件 当某个软件需要创建新窗口的时候...
并发 - 1
...
杂
键入网址到网页显示 网页之间主要通过HTTP或者HTTPS进行访问。如果是Https的话，在端对端之间还需要进行SSL加解密。 接下来则是对网址的解析，首先会将网址分为多部分：域名，访问的路径。http中一般来说会包含多个元素，假如是TCP的话，其中有多个TCP请求体。每个请求体中有mac地址。 访问域名的时候，会首先到DNS域名解析服务器中，对该域名进行解析，如果此域名不行的话，就迭代递归进行解析，直至最后的根域名解析服务器。最后获得对应的ip。有了ip之后，就知道往哪里发了。在以太网中根据这个ip进行路由找到对应的服务器。找到之后，通过mac地址，找到目的地主机。发送成功。
随便写点
关于懒加载和栈堆懒加载在操作系统中的体现可以动态链接和虚拟内存 对于动态链接 我们会在程序的对应部分记录一个空 假如运行到这里了 就会根据PLT和GOT寻找遍历方法 找到对应的方法栈堆区并加载过来 对于虚拟内存 我们则会以进程为单位 分配缓存页 在不同的线程中 他们可能会出现同样的一个地址空间 这个地址空间是虚拟的 在调用到的时候 操作系统会通过CR3（一个存放的寄存器） 查找到其对应的物理地址 并且将这一页加载进来 这本质上就是懒加载的一个鲜活体现 在JVM中 也存在对应的体现 有java虚拟机栈 本地方法栈 两者本质上是存储不同方法的运行时实际数据 而这个栈帧的加载就是懒加载 当运行到这个方法的时候...
IM Server
图搬运tbd IM server此md记录学习im相关的一些笔记 确保 QOS2 + 时序性 可达性 准确性 时序性 消息按照时间顺序排列 关于字符流和字节流： 字符流可读 但是其效率不如字节流 传输的时候不需要转化 字节流在传输的时候需要进行序列化等操作 但是其传输效率高 小公司（几百QPS）一般使用的是字符流多 但是大规模项目一般使用字节流 且protobuf TCP &...
IMdesign -- 读写放大的思考
本文主要围绕个人在设计IM中核心业务（信息收发）中的存储&缓存层的构建时的一些思考。苦逼大学生，才疏学浅，请多指教！ 上文分析了大Key和热Key问题，但是仍没有解决第一文就提出的查询映射关系时的性能瓶颈问题。此文将针对此问题展开讨论。 读写放大 目前的架构按照将用户根据userID等类型进行分类存储，由于每个用户在每条信息上的状态都不一样（用户间信息特征具有唯一性）。所以在下发的过程需经过userID -> sessionID -> deviceID的路线进行多次查询。如上文所说这是其中一个性能瓶颈，也就是所谓的读放大问题。 读放大 Q：严谨地解释一下读放大问题定义 A：读放大问题（Read...
IMdesign -- 大Key问题（session绑定）与热Key问题
本文主要围绕个人在设计IM中核心业务（信息收发）中的存储&缓存层的构建时的一些思考。苦逼大学生，才疏学浅，请多指教！ 回到上文所留下的问题，在设计缓存时，某些不收敛的业务场景。随着程序运行数据的积压，会不可避免的形成大Key，并且会有部分Key访问量大，即热Key。两者对程序运行均有伤害，下方将分析部分优化的解法。 大Key 问题大Key问题指的是在使用缓存或存储中间件（如Redis）时，单个Key对应的Value非常大，导致一系列性能和稳定性问题。主要包括：占用大量内存资源，网络传输需要较长时间与带宽，迁移困难等等。 主要可以从业务上 & 架构上着手优化： 架构层面上若抛开业务上的优化空间，业界对于此问题的解决方案为拆分Key，压缩Key，或结合持久性KV 拆分Key：将原单Key根据大小均衡分片至多个Key中。可在原Key的基础上加入分片的序列号，在获取值时，使用mGet一并获取所有分片的值即可。（mGet同时获取多个键的值 并同时返回） eg:user1 -> user1.1 + user1.2 +...
IMdesign -- 基础表拆分 & 缓存策略的思考
本文主要围绕个人在设计IM中核心业务（信息收发）中的存储&缓存层的构建时的一些思考。苦逼大学生，才疏学浅，请多指教！ 基础表拆分事不宜迟，首先非常简单暴力的概括一下信息收发中表拆分的业务需求，无非就是： 三关系表：user_to_user \ user_to_device \ user_to_session 单消息表（每条消息所具有的信息）：msg(userId, sessionId, msgId, seqId, content, type, is_delete) 单消息状态表：msg_state(userId, msgId, type) 对于关系表： 用户 & 用户：两用户间好友or黑名单等关系 用户 & 设备：在此IM上，同一用户在any设备上登录。记录用户的登录设备信息。用于下发信息 & 消息漫游等业务 用户 & 会话：用户是某个群聊 or 私聊的成员 消息表：记录每条信息的 发出者，发出群聊，消息的唯一标识符，序列号（保证单群聊内信息的时序性），具体内容，信令类型（正常信息 or...
Docker
docker相关卸载docker12345678yum remove docker \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-engine No match for argument: dockerNo match for argument: docker-clientNo match for argument: docker-client-latestNo match for argument: docker-commonNo match for argument: docker-latestNo match for argument: docker-latest-logrotateNo match for argument: docker-logrotateNo match for argument:...