cczywyc

最近 GitHub 官方博客更新了一篇文章，讲述了将 GitHub 网站依赖的 1200+ 台 MySQL 主机升级到 8.0 版本的过程。 先前，Oracle 官方宣布，在 2023 年 10 月 21 日之后，MySQL 5.7 将达到其生命周期的终点，这意味着 Oracle 将不再为 MySQL 5.7 提供官方更新、错误修复或安全补丁，正是在这一背景下，才有了 GitHub 此次的升级。 根据 GitHub 官方介绍，GitHub 使用 MySQL 来存储大量关系数据，因此对于数据库这种底层的基础设施的升级绝非易事，为了升级到 MySQL 8.0，他们规划、测试和升级本身总共花费了一年多的时间，并且需要 GitHub 内部多个团队的协作。因此对于 GitHub 此次这种大规模的底层数据库的升级，我本身是抱有极大的兴趣，也想了解一下如此大规模的 MySQL 的集群采用了什么样的升级方案，所以我去阅读了 GitHub 官方博客，并且将原文翻译如下，以下是原文翻译全部内容。 15 年前，GitHub 开始于一个使用 Ruby on Rails（cczywyc 注：一个基于 R...

最近在公司负责几个二层网络、三层网络相关的项目，项目推进的过程中也掌握了一些交换机和网络虚拟化相关的知识。在之前我接触到的可能更多是三层、四层网络相关的知识，刚好借着这次项目经验总结梳理一下二层网络设备和云计算中网络虚拟化相关的知识。 交换机概述什么是交换机交换机是一种网络硬件设备，用于连接多台设备（如计算机、服务器、打印机等），使它们能够在一个局域网（LAN）内通过数据包进行通信，现如今，交换机是包括互联网在内的现代 IT 网络的基本组成部分之一，它解决了设备间通信的问题。 交换机接受一个设备的数据包，并且将数据包发送到指定的设备上去，从而实现设备间高效通信。交换机是如何知道它收到的数据包应该发往哪个设备呢？其实是通过 MAC 地址来实现的，交换机收到的网络报文头里包含了源 MAC 地址和目的 MAC 地址，然后交换机在它的地址表中找到对应的网络设备，从而将数据包发往指定的设备。关于交换机具体的工作原理，将在下面具体介绍。 交换机类型从网络模型上来看，我们说的交换机一般都是指的工作在二层网络模型上面的交换机，我们称为二层交换机，它通过检查数据帧的目标 MAC 地址，将数据帧发送...

上篇文章记录了我在服务器上搭建了自己的 RSS 服务，经过一段时间的体验使用，我发现 RSS 这种信息获取的方式的确很适合我。在深入使用的过程中，也逐渐总结了一些 tt-rss 的优缺点，先说我认为好的方面： 丰富的主题 完善的插件系统 支持独立部署 功能齐全 同时我也认为它有不好的地方（个人主观观点）： PHP 驱动实现，稍有笨重，不够”现代化“ 虽然有较为丰富的主题，但整体 UI 风格不是特别喜欢 用户系统不够完善，可玩性不高 不支持除 RSS 订阅以外的形态，例如：网页、文章阅读清单功能 基于上述，我决定自己开始探索这种类 RSS 阅读器的产品形态，自己做一个类 RSS 阅读器。 目前，大部分的博客网站都是支持 RSS 的，不支持 RSS 的网站，也有 RSS Hub 这样的产品帮助我们解决问题。RSS 文件订阅类型一般有 rss、atom、json类型，文件格式为 XML 和 JSON。网站将网站的内容信息整合到一个 RSS 文件中，这个文件我们一般称为 feed，也叫信源。在 RSS 文件里面具体包含了网站的标题、描述、作者信息、文章列表等信息，并且随着网站内容...

先来简单说一下什么是 RSS 吧，RSS 全称叫做 Really Simple Syndication，中文叫做简易信息聚合，也叫聚合内容，它是一种消息来源格式规范，用以聚合多个网站更新的内容并自动通知网站订阅者。使用 RSS 后，网站订阅者便无需手动查看网站是否有新的内容，同时 RSS 可将多个网站更新的内容进行整合，以摘要的形式呈现，有助于订阅者快速获取重要信息，并选择性地点阅查看。说的简单点就是它可以把各种信息源整合起来，我只需要在一个 RSS 服务里面就可以获取到来自各种不同渠道的订阅更新，现在我们看到个很多技术博客和网站都提供了 RSS 订阅链接，细心的话你应该在很多地方就见过这个东西。 说来奇怪，RSS 本应是上个时代的产物，近些年缺被越来越多的人追捧，在目前这个信息爆炸的时代，各种信息流充满着我们的屏幕，不同的信息平台也有着不同的推送方式，导致信息获取破碎，无法筛选自己真正感兴趣的信息。如果你跟我有差不多同样的想法，那么，搭建一个自己的 RSS 服务就显的很有必要了。 我的信息获取来源，一方面是一些微信公众号，还有一些技术博客和刊栏，导致我的信息获取非常的分散不集中...

背景2023 年 09 年 20 日，Java21 正式发布，这是最新的 LTS 版本，官方预计会对此版本提供至少 8 年的维护。这一次 JDK 的升级是否会引起 Java8 项目升级暂不清楚，但是此版本带来了诸如虚拟线程等重量级功能更新，可能会导致 Java21 版本将会成为未来几年最经典的 JDK 版本，就像曾经的 Java8 一样。 新功能介绍此次 Java21 版本一共带来了 15 个新功能更新，具体可以见官方的发布页面，一眼望去，其中最重磅的更新摸过于 JEP444，也就是我们所说的虚拟线程，一般我们在其他语言（比如 golang）里面叫做协程。除此之外，还有诸如分代 ZGC、Switch 模式匹配等实用功能的更新，以下是 Java21 版本所有的新功能： 提案 标题 说明 JEP430 String Templates (Preview) 字符串模版。Java 语言现有字符串文本和文本块增加功能，其他常用语言均已提供相应的功能用法 JEP431 Sequenced Collections 序列集合。该 JEP 提议引入”一个新的接口族，用于表示集合的概...

经过两个多月断断续续的面试，工作终于是在 6 月份敲定了，不管结果如何，好在终于做出了选择，综合考虑，选择了一家了还算不错的公司，正式开启了职业生涯的第二阶段。其实这篇文章 6 月份就应该写的，之所以拖到现在一方面是刚去新环境需要一个时间过渡，另外一方面则是一直没制定好下一个阶段的计划。 按照习惯，先总结一下过去两个多月吧，找工作是一个及其痛苦的过程，两个多月的时间里，我要随时保持面试状态，学习也是以八股和面试为主，面试本身也极大的消耗了我的精力。我清楚的记得，过去两个月经常失眠，夜晚思绪乱飞，常常因为理想和现实差距过大而焦虑，要达到理想中的目标还需要付出太多。上周有天晚上跟妹子聊到这个问题，她跟我说到每个有成就的人可能都会经历从基础的物质享受到实现自身价值的阶段，这其中伴随着理想的实现，对普通人来说，美好的事物往往都是从煎熬中获得的。老实说，在现在这样的环境下我不一定完全认同这些观点，但是我觉得为什么不再坚持一下呢？就是这样伴随着焦虑和自我怀疑结束了毕业以来的第一次社招，我成功换了一家公司工作。可能对其他人来说，这不是一个多么好的 offer，但是这是我现阶段最好的选择，我很感...

概述SSH 全称 The Secure Shell protocol，它是应用层上的一种加密的网络传输协议，可在不安全的网络中为网络服务提供安全的传输环境，它是通过在网络中创建安全隧道来实现 SSH 客户端与服务器端之间的连接。SSH 协议最常见的用途是远程登录系统，人们通常使用 SSH 来传输命令行界面和远程执行命令，因此可以说它是我们使用最频繁的网络协议之一。 在设计上，SSH 是 telnet 和非安全 shell 的替代品，Telnet 和 Berkeley rlogin、rsh、rexec 等协议采用明文传输，使用不可靠的密码，容易遭到监听、嗅探和中间人攻击。SSH 旨在保证非安全网络环境（例如互联网）中信息加密完整可靠。 定义SSH 协议先后定义在多个RFC文档中，以下列出了 SSH 协议相关的一些重要的 RFC。 RFC 介绍 时间 RFC 4250 协议号码 2006 年 01 月 RFC 4251 协议架构 2006 年 01 月 RFC 4252 身份验证 2006 年 01 月 RFC 4253 SSH 传输层协议 2006 年 01...

前言关于这篇文章起因，最近计划看一下《Effective Java》，然后我了解到此书的作者同样也是 Google Guava 库的作者，作为一个练习2年的 Java 的程序员，还没有研究过 Guava，属实有点说不过去，借此机会研究了一下 Google Guava。 先简单说一下 Google Guava 库，它不仅仅是 JDK 的升级库，诸如包含集合（collections）、缓存（caching）、并发库（concurrency libraries）、原生类型支持（primitives support）、字符串处理（string processing）、I/O 库等，还是《Effective Java》这本书中那些优秀经验的实践代表，两者应该结合起来阅读学习。在 Guava 中有两个实现我很感兴趣，一个是它实现的 Bloom Filter（布隆过滤器），另外一个就是本篇文章即将介绍的 RateLimiter（限流器）。 我们平时在开发高并发的分布式系统时，会借助许多手段来满足系统的并发要求，我总结下来大致分为下面几个方面： 缓存：通过缓存系统可以减少对底层数据存...

又是一年的校招季，最近有几个学弟学妹过来询问我关于校招的许多事情，诸如校招到现在没有offer怎么办、校招该如何准备等等一些这样的问题。我向来不喜欢好为人师，主要是我觉得我的阅历还远远不够，给别人提供不了什么有价值的建议，但是诸如此类的问题倒是确实引起了我的思考，那就是我们技术人员到底该如何提高自己呢？ 带着这样的思考，我阅读了不少大牛的博客、帖子，试图从他们身上看到一个技术大牛的发展之路，有耗子叔出品的练级攻略和一系列的学习方法论，也有云风一路发展的记录，这些都让我有了不少的思考，于是你看到了这篇文章。需要特别说明的是，我本身没有特别丰富的人生经验和阅历，此文也仅代表我的一些阅读思考，并且这篇文章讨论的更多是技术人员在技术层面上的提升，如果你希望在这篇文章寻找捷径或者想在非技术层面上和我交流，那么这篇文章可能不适合你，就没有必要读了。 我将从以下四个方面来表达我的观点。 关于学习态度我经常看到有人说：今天开始我一定要好好学习，这个月我要学完xxxx，一般这样的口号喊出来以后，没过两天就好像泄气了，再也没有再听他说关于学习的事情，是的，曾经定下的宏伟目标，99%的人都没有坚持下来...

前言C10K 问题C10K 问题是由Dan Kegel在1999年提出的。C代表并发连接，指的是在一个单机网络服务器能够同时1万个并发请求。在过去很长一段时间，这个目标一度是很难实现的，所以也就产生了C10K的问题，但是随着网络技术的发展，C10早已经被解决，现如今已经不再是一个具有挑战性的问题了。 上面提到的C10K问题，是在32位Linux2.2内核的机器上遇到的问题，在当时由于机器的内存、网卡和网络带宽等硬件的限制，人们发现很难突破这个问题。随着电子工业的发展，根据摩尔定律，计算机的处理能力，每隔一段时间都会翻倍， 计算机的处理能力已经渐渐不再是瓶颈。与此同时，随着网络技术的发展，网络连接的IO模型和架构模式也在不断的发展，在现如今分布式集群的环境下，当时的问题虽然早已经不复存在，但是弄清楚背后的原理，能够帮助我们写出高性能的程序。 IO 模型的演进随着操作系统内核的发展，推动软件技术的进步，结合编程语言的支持，诞生了许多种不同的IO模型，大致概括为一下五类： 阻塞式 IO阻塞式IO也就是一对一建立连接，一个客户端和一个服务端建立连接，在服务端返回数据之前，客户端会阻塞，...