Mysql--事务(mvcc+间隙锁)
Mysql 事务(mvcc+间隙锁)事务隔离提到事务,你肯定会想到 ACID(Atomicity、Consistency、Isolation、Durability,即原子性、一致性、隔离性、持久性),今天我们就来说说其中 I,也就是“隔离性”。
当数据库上有多个事务同时执行的时候,就可能出现脏读(dirty read)、不可重复读(non-repeatable read)、幻读(phantom read)的问题,为了解决这些问题,就有了“隔离级别”的概念。
在谈隔离级别之前,你首先要知道,你隔离得越严实,效率就会越低。因此很多时候,我们都要在二者之间寻找一个平衡点。SQL 标准的事务隔离级别包括:读未提交(read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串行化(serializable )。下面我逐一为你解释:
读未提交是指,一个事务还没提交时,它做的变更就能被别的事务看到。
读提交是指,一个事务提交之后,它做的变更才会被其他事务看到。
可重复读是指,一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数 ...
程序员如何为女朋友做迪士尼攻略
程序员如何为女朋友做迪士尼攻略
身为一个程序员,我们每天大多时间对着计算机没有交际应酬,更不懂得浪漫与体贴。我能为女朋友做点什么呢?我是不是能用我的专业来帮女票做点事情。刚好女票生日计划去迪士尼玩,做攻略的重任就落到了我的身上。
我利用数据和逻辑科学的帮助女友生成了一份攻略,代码在这里
前言我在苦思冥想该怎么做攻略的时候看了很多小红书,视频,还有直播,我发现他们都会给出游玩攻略。但很可惜他们清一色的就是告诉你该以什么顺序去玩却不告诉你形成攻略的具体逻辑是什么,他们形成攻略的说辞基本就是靠经验,这对于我一个逻辑至上的程序员来说是不能忍受的。所有的up主都千篇一律的就是第一个冲翱翔地平线,第二个小矮人矿车。。。
我知道他们通过经验形成的逻辑点就是在最早的时间冲最火的项目,这样在主观感受上确实是可以节省更多时间。但最火的项目在早上不也一样是最火的?不也一样等的时间比其他的久,在所有项目都接近排队时长最短的黄金早晨时间项目排队耗费时间也是能否玩更多项目的关键。
我觉得可以根据多日的单项目不同时间点平均等待时间辅以一些算法来获取一个项目游玩优先级权重。
攻略思路在早8:00 - 9:00 时间 ...
深入理解 Docker
深入理解 Docker
随着云计算技术的发展,容器技术应运而生,他解决了大家在本地,测试,线上等不同环境下进行构建,部署的环境不统一的蛋疼问题,随之而来的是Kubernetes、微服务架构等新技术新思想这些技术不仅将各种繁琐的构建,部署环境问题完全隔离,我们的服务也向高可用, 可拓展的方向精进。
容器是如何解决环境统一性的问题的?有是如何做到统一环境的快速复制迁移的?带着这些问题我们来深入了解些容器(Docker)。
本文章为张磊老师的《深入剖析Kuernetes》容器部分的整合
Docker 是什么容器其实是一种沙盒技术。它可以让开发者将应用程序和依赖项打包成一个可移植的容器,从而实现快速部署、可移植性和可伸缩性。Docker 技术基于 Linux 容器(LXC)技术,通过隔离应用程序和依赖项的运行环境,使得应用程序在不同的计算机环境中能够保持一致的运行效果。
所谓 Docker 镜像,其实就是一个压缩包。但是这个压缩包里的内容,比 PaaS 的应用可执行文件 + 启停脚本的组合就要丰富多了。实际上,大多数 Docker 镜像是直接由一个完整操作系统的所有文件和目录构成的,所以这个 ...
Tunny 库源码深度解读
Tunny 库源码深度解读
Tunny 库是一个用于生成和管理goroutine池的Golang库,制定一个方法可以限制该方法并发量及控制生命周期。这是一个设计简单但功能强大且通用易用的库,之前我们说过 Machinery 库,该库功能当然强大的多,他支持分布式且支持不同任务的编排,Tunny就没有这种功能,但Tunny库异常简单轻量如果不是大型的事件推动型项目,那么Tunny就足够支持其场景。
本文解读一下Tunny库的源码并且对比 Machinery 库来总结下两位作者在设计通用场景功能时的不同思路。
源码解读架构我们先来看看Tunny 库的大体架构:
主体pool:123456789101112// Pool is a struct that manages a collection of workers, each with their own// goroutine. The Pool can initialize, expand, compress and close the workers,// as well as processing jobs with the w ...
Go 语言使用定时调度任务大杀器 — XXL-JOB
Go 语言使用定时调度任务大杀器 — XXL-JOB
XXL-JOB 是一个分布式任务调度平台,其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线,开箱即用。
本文将以一个 gopher 的视角教你跳过 java 环境,做到仅仅使用 golang 也可以开箱即用,玩转 XXL-JOB。
XXL-JOB 使用文档
为什么要用XXL- JOB 在我看来可以替代我们系统中所有定时任务调度,因为定时任务的不可掌控,尤其是在分布式集群中。如果一个任务失败了那么我们首先无法即时发现,其次我们就算发现了也没法去重新触发他来解决问题,解决问题只能靠重启服务,但有的服务又不能随便重启,打个比方:行情服务,他一直在不断的接收数据流,重启势必造成数据丢失,丢失都还是好的重启服务还会造成数据堆积,消息队列阻塞,数据更新延迟,所以一旦这种服务的定时任务出现问题你只有任他发展。这个时候 XXL- JOB 这个应用就成了解决问题的大杀器。
定时及手动调度支持
它帮你承担了调度的任务,支持 cron 方式定义任务的定时调度,同时支持手动出发任务。
多种任务注册模式
主 ...
Mysql--索引
Mysql 索引InnoDB 的索引模型在 InnoDB 中,表都是根据主键顺序以索引的形式存放的,这种存储方式的表称为索引组织表。又因为前面我们提到的,InnoDB 使用了 B+ 树索引模型,所以数据都是存储在 B+ 树中的。
每一个索引在 InnoDB 里面对应一棵 B+ 树
根据叶子节点的内容,索引类型分为主键索引和非主键索引。
主键索引的叶子节点存的是整行数据。在 InnoDB 里,主键索引也被称为聚簇索引(clustered index)。
非主键索引的叶子节点内容是主键的值。在 InnoDB 里,非主键索引也被称为二级索引(secondary index)。
如果语句是 select * from T where ID=500,即主键查询方式,则只需要搜索 ID 这棵 B+ 树;
如果语句是 select * from T where k=5,即普通索引查询方式,则需要先搜索 k 索引树,得到 ID 的值为 500,再到 ID 索引树搜索一次。这个过程称为回表。
也就是说,基于非主键索引的查询需要多扫描一棵索引树。因此,我们在应用中应该尽量使用主键查询。
索引维护B+ 树为 ...
Mysql--锁
Mysql 锁根据加锁的范围,MySQL 里面的锁大致可以分成全局锁、表级锁和行锁三类
全局锁顾名思义,全局锁就是对整个数据库实例加锁。MySQL 提供了一个加全局读锁的方法,命令是 Flush tables with read lock (FTWRL)。当你需要让整个库处于只读状态的时候,可以使用这个命令,之后其他线程的以下语句会被阻塞:数据更新语句(数据的增删改)、数据定义语句(包括建表、修改表结构等)和更新类事务的提交语句。
全局锁的典型使用场景是,做全库逻辑备份。也就是把整库每个表都 select 出来存成文本。
以前有一种做法,是通过 FTWRL 确保不会有其他线程对数据库做更新,然后对整个库做备份。注意,在备份过程中整个库完全处于只读状态。
但是让整库都只读,听上去就很危险:
如果你在主库上备份,那么在备份期间都不能执行更新,业务基本上就得停摆;
如果你在从库上备份,那么备份期间从库不能执行主库同步过来的 binlog,会导致主从延迟。
其实是有一个方法能够拿到一致性视图的,对吧?
就是在可重复读隔离级别下开启一个事务。
官方自带的逻辑备份工具是 mysqldump。当 ...
Mysql--排序
Mysql 排序Order by在你开发应用的时候,一定会经常碰到需要根据指定的字段排序来显示结果的需求。还是以我们前面举例用过的市民表为例,假设你要查询城市是“杭州”的所有人名字,并且按照姓名排序返回前 1000 个人的姓名、年龄。
1select city,name,age from t where city='杭州' order by name limit 1000 ;
全字段排序前面我们介绍过索引,所以你现在就很清楚了,为避免全表扫描,我们需要在 city 字段加上索引。在 city 字段上创建索引之后,我们用 explain 命令来看看这个语句的执行情况。
Extra 这个字段中的“Using filesort”表示的就是需要排序,MySQL 会给每个线程分配一块内存用于排序,称为 sort_buffer。
通常情况下,这个语句执行流程如下所示 :
初始化 sort_buffer,确定放入 name、city、age 这三个字段;
从索引 city 找到第一个满足 city=’杭州’条件的主键 id,也就是图中的 ID_X;
到主键 id 索引取出 ...
K8s编排对象 -- POD
K8s编排对象 – POD
Pod,是 Kubernetes 项目中最小的 API 对象。如果换一个更专业的说法,我们可以这样描述:Pod,是 Kubernetes 项目的原子调度单位。
引入POD的意义“Namespace 做隔离,Cgroups 做限制,rootfs 做文件系统”这样的“三句箴言”可以朗朗上口了,为什么 Kubernetes 项目又突然搞出一个 Pod 来呢?
要回答这个问题,我们要先弄清一个问题:容器的本质到底是什么?
容器的本质是进程!没错。容器,就是未来云计算系统中的进程;容器镜像就是这个系统里的“.exe”安装包。那么Kubernetes 呢?Kubernetes 就是操作系统!
弄清这些后,就让我们登录到一台 Linux 机器里,执行一条如下所示的命令:
1pstree -g
这条命令的作用,是展示当前系统中正在运行的进程的树状结构。
123456789101112131415161718systemd(1)-+-accounts-daemon(1984)-+-{gdbus}(1984) | `-{gm ...
K8s的设计理念与架构
K8s的设计理念与架构设计理念Kubernetes 项目的理论基础则要比工程实践走得靠前得多,这当然要归功于 Google 公司在 2015 年 4 月发布的 Borg 论文了。Borg 系统,一直以来都被誉为 Google 公司内部最强大的“秘密武器”。虽然略显夸张,但这个说法倒不算是吹牛。因为,相比于 Spanner、BigTable 等相对上层的项目,Borg 要承担的责任,是承载 Google 公司整个基础设施的核心依赖。在 Google 公司已经公开发表的基础设施体系论文中,Borg 项目当仁不让地位居整个基础设施技术栈的最底层。
Kubernetes 项目在 Borg 体系的指导下,体现出了一种独有的“先进性”与“完备性”,而这些特质才是一个基础设施领域开源项目赖以生存的核心价值。
为了更好地理解这两种特质,我们不妨从 Kubernetes 的顶层设计说起。
首先,Kubernetes 项目要解决的问题是什么?编排?调度?容器云?还是集群管理?实际上,这个问题到目前为止都没有固定的答案。因为在不同的发展阶段,Kubernetes 需要着重解决的问题是不同的。但是,对于大多数 ...