More issues

常见的CI/CD工具

前言 CI/CD是一种软件开发流程，它将持续集成（Continuous Integration）和持续交付/部署（Continuous Delivery/Deployment）两个概念结合起来，旨在加速软件的交付和部署，提高软件质量和稳定性。 持续集成指的是将开发人员提交的代码自动集成到主干代码库中，然后运行一系列的测试和检查，以确保代码的质量和稳定性。这样可以避免代码冲突、降低代码合并的复杂度，同时也可以及时发现和解决代码问题，提高代码的可维护性和可测试性。 持续交付/部署则是指将经过测试和检查的代码自动部署到生产环境中，以实现快速的软件交付和部署。持续交付/部署需要借助自动化工具和流程来实现，包括自动化测试、自动化构建、自动化部署等。这样可以减少人为操作的错误和延迟，提高软件交付的速度和质量。 CI/CD的优点在于它可以加速软件开发和交付的速度，同时也可以提高软件的质量和稳定性。它可以帮助开发团队更快地响应市场需求和用户反馈，减少开发周期和成本。另外，CI/CD还可以提高开发团队的协作效率和代码管理的可靠性。 实现CI/CD需要借助一系列的工具和技术，包括版本控制工具、自
— 5 min read

JUC复习篇（二）锁的认识

锁的基本概念： 通过锁机制，能够保证在多线程环境中，在同一时间空间中，只能有一个线程进入临界区代码，从而保证临界区中操作数据的一致性。 公平锁： 防止某个线程出现饿死现象，也就是防止某个线程分配不到CPU时间片导致指令一直无法执行。保证公平需要额外维护线程状态，更多的线程上下文切换，开销更大，吞吐量有所下降。ReentrantLock 可用设置初始化参数设置为公平锁，Synchronized默认是非公平锁并且不能变为公平锁。 非公平锁： 直接进行计算资源抢夺，容易出现线程饿死现象。但吞吐量更高，线程切换不那么频繁，谁先抢到CPU时间片即可执行。 可重入锁： 又称为递归锁，可以再次获取已经获取到的锁对象，可以一定程度的避免死锁现象。ReentrantLock和Synchronized都是可重入锁。 不可重入锁： 线程在运行中获取到锁之后，在同步代码块种再次获取这把锁将会导致死锁，不可重入锁只允许在同步代码块中被获取一次。 互斥锁： 当一个线程占用资源时，其他线程会被挂起，不会占用CPU资源，锁被释放时，CPU去调度挂起的线程，适合不会被高频操作的资源，否则频繁调度线程的效率会较
— 8 min read

JUC复习篇（一）线程基础

前言 Java JUC章节的知识点繁多，为了更好的整理我掌握的知识点，故此通过书写博客的方式，其中从底层原理开始梳理，从而总结出自己对并发编程的理解。 什么是并发编程 原因还得从目前的计算机发展历史说起，根据摩尔定律，计算机CPU算力随着时间越来越高，但摩尔定律很快达到物理极限，单核心CPU算力遇到瓶颈，而人们为了追求更高的算力，使用了多核心CPU架构设计，多核心与超线程技术使得CPU算力大幅度提高。原理相当于有多个人同时执行不同的指令，整体效率当然比一个人执行得更高。（注意是整体效率更高，不意味着使用多线程就一定比单线程应用执行指令效率更高） 为了更好的运用多核心CPU的计算资源（压榨CPU），于是产生了多线程开发。虽然使用多线程在某些场景下确实提高了程序整体效率，但多线程也并不是银弹，使用多线程开发随之而来的也有诸多问题，例如：线程安全问题、锁机制、死锁、线程上下文切换带来的开销等问题。 那么说了这么多线程的描述，到底什么是线程呢？ 线程是操作系统能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程
— 12 min read

Kubernetes 部署 Istio

前言 kubernetes 虽然已经解决了运维上的大部分问题，拥有着优秀的自动运维机制。例如：动态扩容，调度，镜像管理，容器宕机重启，计算节点监控等问题。但k8s在应用层上的监控与流量管理，应用之间的相互调用调用协调，注册中心，配置中心等功能并未提供。 于是便出现了基于Service-Mech架构的代表产品Istio。 Istio 是 Google、IBM、Lyft 三家联合开发的框架，主要作用于在 k8s 环境中微服务之间流量控制、连接、保护、设置和观测服务。使得我们开发微服务时可以抛弃掉繁琐、复杂、维护性低、强耦合性的底层微服务SDK。 Istio架构 在架构上Istio分为数据平面与控制平面。 数据平面的核心思维就是Sidecar（边车模式），在同一个pod中，添加proxy代理容器，接管我们的业务容器流量，在不对业务代码有任何入侵的前提下，从而实现各种功能，例如：负载均衡、流量加密、监控、策略（灰度发布、蓝绿发布）、熔断、降级、远程服务调用、
— 5 min read

kubectl 常用命令

kubectl --help ：帮助信息 kubectl delete Deployments -n <命名空间> kubectl get nodes ：查看集群节点数 kubectl get pod -n <命名空间> ：查看对应命名空间下pod信息 kubectl get pods -A 查看所有pod kubectl get namespace ：查看命名空间 kubectl get pod --all-namespace 查看所有命名下的pod kubectl apply -f ：应用pod配置文件，设置资源 kubectl delete -f ：取消应用pod配置文件，删除资源 kubectl create 通过yaml/json 文件或者标准输入创建一个资源对象 kubectl drain
— 1 min read

K8S Kubeadm 搭建流程

前言 将最近搭建的K8S流程，以及遇到的部分问题，作为笔记进行记录。 部署环境 搭建版本：kubernetes-1.24.4 （HA） 容器运行时：containerd-1.6.8 操作系统：CentOS7 前置条件 1、集群节点计算资源必须是2h-cpu 2g-ram以上的机器，节点内网或公网需要可达。 2、每个机器的hostname，mac地址不能相同，唯一性product_uuid，通过hostname可以访问对应节点，需要配置/etc/hosts文件。 3、kubernates 1.24版本后默认的容器运行时不再使用Docker，改为 Containerd 容器运行时，如果需要使用docker则需要安装cri-dockerd。 4、 HA架构必须存在3个master控制平面节点，架构如下图：（高可用分为堆叠etcd，外部etcd）。 外部etcd 优点：其中失去控制平面实例或者 etcd 成员的影响较小，并且不会像堆叠的 HA
— 11 min read

HBase介绍以及对比MongoDB

HBase全称：Hadoop Database。 HBase是一种高可靠性，高性能，面向列的可扩展分布式存储系统，使用HBase技术在廉价的PC服务器上构建大规模结构化存储集群。 HBase的目标是存储和处理大量数据，特别是仅使用标准硬件配置即可处理包含数千行和列的大量数据，可处理PB级别数据存储，亿级QPS查询。 它适用于实时性要求不高的业务场景，HBase存储Byte数组，该数组不介意数据类型，从而允许动态，灵活的数据模型。 架构解析： HBase由HMaster和HRegionServer组成，并且遵循主从服务器体系结构。 HBase将逻辑表分为多个数据块HRegion，并将它们存储在HRegionServer中。 HMaster负责管理所有HRegionServer。 它本身不存储任何数据，而仅存储数据到HRegionServer的映射(元数据)。 群集中的所有节点均由Zookeeper协调，并处理HBase操作期间可能遇到的各种问题。 HBase的基本架构如下所示： 客户端：使用HBase的RPC机制与HMaster和HRegionServer通信，提交请求并获得
— 13 min read

Redis 缓存一致性

缓存一致性 首先我们先说说什么是缓存一致性问题，为什么要解决，以及方案是什么。 缓存一致性问题是指在使用缓存时，由于缓存数据与数据库数据的不一致性，可能会导致数据错误或者数据丢失等问题。这种问题在高并发场景下尤为常见，因为多个线程同时读写同一份数据时，很难保证数据的一致性。如何保证和Redis内存中的数据与DB数据库中的数据保持一致，并且不能出现数据不一致的情况（高并发场景中），如果出现数据不一致对于某些情况来说可能会出现大麻烦，缓存一致性的解决方案也很重要。 以下是我列出常见的几种方案，以及它们在高并发场景下各自的问题。 直接写入缓存 （不推荐） 在3，4步执行时高并发场景下无法保证写入Redis数据的Java线程会进行顺序执行（因为CPU时间分片问题，并且加上分布式、微服务情况更加明显）。才会导致最新数据可能被其他线程中的旧数据覆盖，如果发生了之后后续没有其他线程执行，可能缓存数据一直会保持旧数据情况。 这里可能有人会直接使用分布式锁（单应用加JVM锁即可），加锁需要控制整个DB写入到Redis写入的流程，并且每个Key操作的函数范围需要自己把控，且效率肯定下降得厉害
— 4 min read

Redis 缓存穿透，击穿，雪崩

缓存穿透 缓存穿透是指用户请求的数据在缓存中不存在即没有命中，同时在数据库中也不存在，导致用户每次请求该数据都要去数据库中查询一遍，然后返回空。 如果有恶意攻击者不断请求系统中不存在的数据，会导致短时间大量请求落在数据库上，造成数据库压力过大，甚至击垮数据库系统。 解决方案： （1）布隆过滤器 布隆过滤器实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。 如果想要判断一个元素是不是在一个集合里，一般想到的是将所有元素保存起来，然后通过比较确定。链表，树等等数据结构都是这种思路. 但是随着集合中元素的增加，我们需要的存储空间越来越大，检索速度也越来越慢(O(n),O(logn))。不过可以使用散列表（又叫哈希表，Hash table）数据结构。它可以通过一个Hash函数将一个元素映射成一个位阵列（Bit array）中的一个点。这样一来，我们只要看看这个点是不是1就可以知道集合中有没有它了。这就是布隆过滤器的基本思想。 （2）返回空 当缓存未命中，查询
— 5 min read

Redis 主从，哨兵，集群搭建

前言 记录一下自己对 redis 主从，哨兵，集群三种模式搭建流程，redis的所有部署模式都不复杂，主要是对配置文件的书写，以及各个模式的优缺点分析。 RedisRedis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message brokerRedis 部署环境 操作系统 CentOS7 Redis版本：Redis7.0.5 主从模式 优点：配置简单，快速，读写分离，完全分担了主节点的读压力，并且从节点还可套娃继续配置多层从节点。 缺点：非高可用，主节点宕机，则失去写能力，数据冗余量大，每个从节点100%复制主节点数据。 非高可用架构，
— 16 min read

关于Serverless架构

背景 Serverless（无服务器架构）近年来逐渐成为云计算领域的一个热门方向。它的核心理念是：开发者无需关心服务器的部署、运维和扩容，只需要专注于业务逻辑的开发。 在传统架构中，一个系统上线通常需要准备服务器、部署环境、配置网络、监控资源以及处理扩容问题，这些工作都需要额外的运维成本。而在 Serverless 架构中，这些基础设施全部由云厂商负责管理，开发者只需要编写函数代码并部署即可运行。 Serverless上云 Serverless 通常以 云函数（Function as a Service，FaaS） 的形式提供。例如阿里云函数计算（FC）、AWS Lambda、腾讯云 SCF 等。开发者只需要上传代码，当有请求触发时，平台会自动运行函数，并根据实际的调用次数和运行时间进行计费。 这种模式带来的最大变化是：应用可以按需运行，而不是长期占用服务器资源。 例如在一些业务场景中： * 定时任务处理 * Webhook 事件触发 * 图片处理 * 数据转换 这些任务并不需要持续运行的服务器，
— 4 min read

Linux 系统不同发行版对比

linux系统有着不同的发行版本，不同的组织对其自己的发行版进行维护。此次笔记记录我认知的部分发行版的区别。 1、Debian 是目前我最喜欢使用的发行版，它的10版本非常稳定，并且系统占用非常小。是目前我在生产环境的选择。 Debian -- The Universal Operating SystemThe Universal Operating System [https://www.debian.org/]2、CentOS 是 Red Hat 从商业收费操作系统的分支版本，在商业操作系统上进行了免费。功能以及稳定性目前也是非常不错，但肯定在某些地方有阉割。毕竟人家有一个收费的系统。并且 CentOS 目前已经停止了维护，原作者 Gregory Kurtzer 也启动了新项目的 Rocky Linux 操作系统。 The CentOS Project [https://www.centos.org/]3、
— 2 min read

血源诅咒

《血源诅咒》是 FromSoftware 制作的一款黑暗风格动作角色扮演游戏，其故事背景建立在浓厚的 克苏鲁神话体系之上，整体世界观充满神秘、疯狂与未知。 本作的主要舞台设定在一座位于遥远东方山区的古老城市 —— 亚楠（Yharnam）。 亚楠是一座极度封闭排外的城市，但却因为一种神秘的医疗技术 “血疗（Blood Healing）” 而闻名世界。据传这种技术可以治愈几乎所有疾病，因此吸引了无数病患、旅人以及研究者远道而来，希望借助血疗摆脱病痛。 然而，随着血疗的广泛使用，一种可怕的瘟疫开始在亚楠蔓延——兽化病（Beast Scourge） 感染者会逐渐失去理智，最终变成疯狂嗜血的野兽。 整个城市因此陷入混乱与恐惧之中，而玩家所扮演的“猎人”，正是在这样的背景下来到亚楠。 随着剧情的推进，玩家会逐渐发现： 兽化并不是简单的疾病，而是与更高层次的存在有关。 上位者与宇宙的真相 在《血源诅咒》的世界中，远古时代存在着一类被称为 “上位者（Great Ones）” 的神秘生命。 这些存在并非传统意义上的神明，而是来自宇宙深处的高维生命。 它们拥有远超人类理解的智慧与力量，
— 4 min read

Linux 目录结构分析

/bin：存放着常用的指令和二进制可程序。 /boot：存放启动Linux系统的内核文件，包括连接文件和镜像文件。 /dev：Device(设备)的缩写，是 Linux 系统目前连接的外部设备，外部设备的访问和文件访问的方式一样。 /etc：专用于存放系统的配置文件和子目录列表。 /home：用户文件夹，每个系统账号都会创建一个不同的文件夹名称。 /root：管理员用户的主目录。 /run：临时文件目录，存储系统启动以来的临时信息，当系统重启，该目录下的文件将会被清理掉。 /opt：optional “可选择”的意思，作用是安装第三方软件的地方 /sbin：管理员用户才能执行的命令和程序文件夹。 /tmp：临时文件目录。10天内未访问、未更该或未修改的文件将自动从这个目录中删除。 /usr：用户应用程序和文件放置的文件夹目录。 /var：存放着经常变动的文件，例如系统日志等文件。
— 1 min read

Linux 挂载新磁盘

1、磁盘连上主板（很重要） 2、重启系统 reboot 3、查看磁盘检查到没有 > fdisk -l 4、进入磁盘 > fdisk /dev/{磁盘名称} 5、把磁盘分区设置好，可以只分一个区 6、格式化分区 > mkfs.ext4 /dev/{分区名称} 7、挂载分区 mount /dev/{分区名称}  /{某个文件夹} 8、设置开启自动挂载，编辑 /etc/fstab 文件 > vim /etc/fstab 添加如下信息 > /dev/(磁盘分区) /（挂载目录） ext4（文件格式）defaults 0 0
— 1 min read

Docker Compose 基本使用

我们安装 docker 之后，便会启动很多容器服务，但对应这些容器如何统一编排，网络组管理，启动顺序，挂载数据卷，成为了问题，于是 docker 团队开发了 docker-compose 组件来便于我们编排容器。 开源项目地址： https://github.com/docker/compose 1、下载文件后上传至服务器 /usr/local/bin 文件夹。 2、添加文件执行权限 sudo chmod +x /usr/local/bin/docker-compose docker-compose 只是一个二进制文件，可以直接运行在 linux 系统上，通过docker-compose 可以使用 yaml 文件来配置应用程序需要的所有容器。然后使用一个命令 docker-compose up -d，就可以从 yaml
— 1 min read

随心笔记

技术无止境 创新不停驻