Redis

一、悲观锁是一种利用数据库内部机制提供的锁的方法，也就是对更新的数据加锁，这样在 并发期间一旦有一个事务持有了数据库记录的锁，其他的线程将不能再对数据进行更新 了，这就是悲观锁的实现方式。 注意，在 SQL 中加入的 for update 语句，意味着将持有对数据库记录的行更新锁（因为这里使用主键查询，所以只会对行加锁。如果使用的是非主键查询，要考虑是否对全表加锁的问题，加锁后可能引发其他查询的阻塞），那就意味着在高并发的场景下，当一条事务持有了这个更新锁才能往下操作，其他的线程如果要更新这条记录，都需要等待，这样就不会出现超发现象引发的数据一致性问题了。 二、 对于悲观锁来说，当一条线程抢占了资源后，其他的线程将得不到资源，那么这个时候，CPU 就会将这些得不到资源的线程挂起，挂起的线程也会消耗 CPU 的资源，尤其是在高并发的请求中 只能有一个事务占据资源，其他事务被挂起等待持有资源的事务提交并释放资源。当图中的线程 1 提交了事务，那么红包资源就会被释放出来，此时就进入了线程 2，线程 3……线程 n，开始抢夺资源的步骤了，这里假设线程 3 抢到资源 三、 一旦线程 1 提交了事务，那么锁就会被释放，这个时候被挂起的线程就会开始竞争红包资源，那么竞争到的线程就会被 CPU 恢复到运行状态，继续运行。 于是频繁挂起，等待持有锁线程释放资源，一旦释放资源后，就开始抢夺，恢复线程

1 背景 最近石墨文档线上业务出现了一些性能问题，在突发流量情况下，有个业务性能急剧下降。该服务是依赖于数据库的业务，会批量获取数据库里的数据。在经过一系列的排查过程后，发现该服务到数据库的连接数经常超过MaxIdleConns，因此怀疑是数据库的配置导致的性能问题，所以以下针对数据库的代码进行了剖析，并做了相关实验。 2 配置解读 maxIdleCount int // zero means defaultMaxIdleConns; negative means 0 maxOpen int // <= 0 means unlimited maxLifetime time.Duration // maximum amount of time a connection may be reused maxIdleTime time.Duration // maximum amount of time a connection may be idle before being closed 可以看到以上四个配置，是我们Go MySQL客户端最重要的配置。 maxIdleCount 最大空闲连接数，默认不配置，是2个最大空闲连接 maxOpen 最大连接数，默认不配置，是不限制最大连接数 maxLifetime 连接最大存活时间 maxIdleTime 空闲连接最大存活时间 3 源码解析

生产级harbor可用的搭建 Harbor简介 Harbor 是一个用于存储和分发 Docker镜像 的企业级 Registry 服务器，通过添加一些企业必需的功能特性，例如安全、标识和管理等，扩展了开源Docker Distribution。 作为一个企业级私有Registry服务器，Harbor提供了更好的性能和安全。 提升用户使用Registry构建和运行环境传输镜像的效率。 Harbor支持安装在多个Registry节点的镜像资源复制，镜像全部保存在私有Registry中， 确保数据和知识产权在公司内部网络中管控。 另外，Harbor也提供了高级的安全特性，诸如用户管理，访问控制和活动审计等。 高可用架构：双主复制 主从同步 harbor官方默认提供主从复制的方案来解决镜像同步问题，通过复制的方式，我们可以实时将测试环境harbor仓库的镜像同步到生产环境harbor，类似于如下流程： 在实际生产运维的中，往往需要把镜像发布到几十或上百台集群节点上。这时，单个Registry已经无法满足大量节点的下载需求，因此要配置多个Registry实例做负载均衡。手工维护多个Registry实例上的镜像，将是十分繁琐的事情。Harbor可以支持一主多从的镜像发布模式，可以解决大规模镜像发布的难题： 只要往一台Harbor上发布，镜像就会像"仙女散花"般地同步到多个Registry中

Sentinel咋一看好像有点熟，这个不是和redis哨兵一样，其实不是一样的，这个是阿里最新开源的一个框架，目的主要是提供限流和熔断，譬如解决过年抢红包大战，防止服务器崩溃的一个解决框架。 历史： 2012年,sentinel诞生,主要功能为入口流量控制 2013-2017年,sentinel在阿里集团内部使用 2018年开源. 网上有很多文章，都挺不错的，分享给大家！ 转载： https://blog.csdn.net/xkuna/article/details/108045882 https://zhuanlan.zhihu.com/p/74280038?from_voters_page=true https://www.cnblogs.com/yinjihuan/p/10468950.html 来源： oschina 链接： https://my.oschina.net/u/3855429/blog/4932898