分享技术见解、生活感悟和成长历程
缓存系统在现在的后台服务中是必不可少的，但缓存系统有很多方面的问题需要我们注意。 缓存穿透 缓存穿透是指当查询一个值不在缓存中的时候，系统会去底层数据库查询，当有大量的流量都命中了缓存中不存在的key那么缓存的存在就起不到作用，底层DB可能会挂掉。如果存在缓存穿透那么这就是漏洞。 解决方案 把查询结果为空的情况我们同样缓存起来，可以把缓存时间设置的稍微短点，当数据更新的时候记得更新缓存数据。 把所有可能存在的数据，哈希到一个 bitmap ，查询的时候使用该 bitmap 过滤不存在的key。 缓存雪崩 缓存雪崩是指缓存系统中的数据在同一时间过期，导致短时间内所有流量都打到底层存储，底层存
HTTPS是建立在安全信道之上的HTTP，使用了传输层加密的方式，而加密的方式就是TLS/SSL，TLS的前身是SSL，因为SSL这一术语比较常用所以我们仍然把证书叫做SSL，其实现在的证书都是TSL的。 TLS/SSL发展历史 1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。 1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。 1996年，SSL 3.0版问世，得到大规模应用。 1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。 2006年和2008
我电脑上原本装了Xcode，但是我电脑是128G，用了两年东西越来越多硬盘不够用了，而我本身开发中很少用Xcode所以就把它卸载了，卸载之后发现Xcode占了11G左右的空间。。 卸载Xcode之后执行git，报错如下： > $ git status xcrun: error: active developer path ("/Applications/Xcode.app/Contents/Developer") does not exist Use `sudo xcode-select --switch path/to/Xcode.app` to specify the Xcode t
Redis 作为高效的缓存数据库，单机也能够表现出很好的性能。但是随着数据的增加、并发的增加，单机模式的 Redis 会受到单机性能、容量、稳定性的限制，即使 Redis 提供了稳定的持久化方案，但是单机服务器始终是部署在单个机器上，如果运行机器本身的服务器出现问题我们很难在短时间恢复服务。所以 Redis 提供了三种多机模式： 主从复制模式 哨兵模式 集群模式 redis集群模式 哨兵模式解决了主节点挂掉的问题，但是没有解决从节点挂掉的问题，而 redis 集群模式可以有效的解决这个问题。redis集群中的数据是和槽（slot）挂钩的，一共定义了16384个槽，所有的数据使用一致性哈希分
Redis 作为高效的缓存数据库，单机也能够表现出很好的性能。但是随着数据的增加、并发的增加，单机模式的 Redis 会受到单机性能、容量、稳定性的限制，即使 Redis 提供了稳定的持久化方案，但是单机服务器始终是部署在单个机器上，如果运行机器本身的服务器出现问题我们很难在短时间恢复服务。所以 Redis 提供了三种多机模式： 主从复制模式 哨兵模式 集群模式 哨兵模式 主从复制模式解决了数据备份和单机可能存在的性能问题，但是也引入了新的问题，一主多从，在使用过程中，如果主服务器挂掉那么整个 Redis 服务的写就挂掉了，如果一个从服务器挂掉那么调用方就无法正确的读数据了，只能通过修改调
在多线程编程中数据争用和竞态条件经常会被提到，怎奈何我写了4年PHP而PHP不支持线程并发编程，虽然这两个概念说的具体问题我还是有所了解，但是初看到这两个概念其实听陌生的。 数据争用 多个线程对同一个变量、同时地、进行读/写操作并且至少有一个线程进行写操作的现象叫做数据争用。如果发生了数据争用，那么一个多线程程序运行完毕时受到数据争用的变量的值是不可预测的。我们可以用锁来避免数据争用。 数据争用的例子（go） package main import ( "fmt" "sync" ) var ( N = 0 waitgroup sync.Wai
关于线程 我们每运行的一个程序都会创建一个进程，每个进程都有一个初始线程，而后初始线程可以创建更多线程，每个线程互相独立地运行。线程因为其轻量和易用性在并发编程中被大量的使用。而 goroutine 就是基于线程的。线程的实现模型主要有3种：用户级线程模型、内核级线程模型和两级线程模型（或者叫做混合型线程模型）。他们之间的区别就是用户线程和系统最小调度单元内核调度实体（KSE，Kernal Scheduling Entity）的对应关系不同。 用户级线程模型 用户线程与内核线程KSE是多对一的映射模型，多个用户线程一般都是从属于单个进程，并且用户线程的调度都是用户程序的线程库完成的，不需要操作
Redis 作为高效的缓存数据库，单机也能够表现出很好的性能。但是随着数据的增加、并发的增加，单机模式的 Redis 会受到单机性能、容量、稳定性的限制，即使 Redis 提供了稳定的持久化方案，但是单机服务器始终是部署在单个机器上，如果运行机器本身的服务器出现问题我们很难在短时间恢复服务。所以 Redis 提供了三种多机模式： 主从复制模式 哨兵模式 集群模式 主从复制模式 主从复制，让一台服务器去复制另外一台服务器，我们称被复制的服务器为主服务器，而对主服务器进行复制的服务器为从服务器。Redis 允许一台主服务器配置多个从服务器。主服务器可以进行读写操作，从服务器只能进行读操作，当主
AOF 持久化是 Redis 提供的另外一种持久化方案，AOF 持久化是将发送到服务端的每一条命令记录下来，并且保存在硬盘的 AOF 文件中。AOF 默认是关闭的，可以通过修改 redis.conf 中相应的配置启动。 appendonly yes # 启动 AOF 持久化，默认是 no appendfilename "appendonly.aof" # AOF 文件文件名 文件同步策略 文件的写入默认情况下会先写入系统的缓存中，系统每隔30秒同步一次，才是真正的写入磁盘，如果这30秒服务器宕机那数据也会丢失。 Redis 可以通过 redis.conf 中的配置设置同步策略 # app
RDB 是 Redis 的一个持久化方案，也是 Redis 默认的持久化方案。RDB 持久化可以手动执行也可以根据服务器配置定期执行。 RDB 持久化所生成的 RDB 文件是一个经过压缩的二进制文件，使用该文件可以还原生成 RDB 文件时的数据库状态。RDB 保存在硬盘上，所以即使 Redis 服务器退出甚至运行 Redis 的服务器停机，但只要 RDB 文件还在就不影响数据的恢复。 RDB文件创建和载入 有两个 Redis 命令可以用于生成 RDB 文件，一个是 SAVE ，另一个是BGSAVE。 SAVE命令会阻塞 Redis 服务器进程，直到 RDB 文件创建完毕为止，在这期间服务器不能