Posts

起因 消息队列处理任务中，由于消息队列中有相同的处理请求并且消费端存在多个，因此出现了并发消费的问题，于是产生了利用分布式锁来锁定消费，保证同一时间只有一个请求在处理，找了一下分布式锁的实现方式常见的有： 基于数据库 基于Zookeeper 基于redis 选型 基于数据库相对来说，更直观，实现起来也比较简单，至于要设置一个唯一索引，在插入时判断是否正常插入，不能插入则说明获取锁失败，缺点是会增加数据库开销，增加数据库压力，所以此方案PASS。基于Zookeeper实现分布式锁，会引新的软件，将会增加原有系统的复杂度，因而此方案也PASS。基于 redis 本身是对内存的操作，相对来说效率会非常高，并且原有系统也已经存在了 redis ，因而也不会增加原系统的复杂度，所以选择了 redis 来实现分布式锁。 背景介绍 SETNX key value 将 key 的值设为 value ，当且仅当 key 不存在。若给的 key 已经存在，则 SETNX 不做任何动作。SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。 redis> EXISTS job # job 不存在 (integer) 0 redis> SETNX job "programmer" # job 设置成功 (integer) 1 redis> SETNX job "code-farmer" # 尝试覆盖 job ，失败 (integer) 0 redis> GET job # 没有被覆盖 "programmer" 当 key 不存在时，返回 1， 如果设置的 key 存在时则返回 0 ，该操作本身具有原子性，因此可以利用 redis 此特性进行分布式锁实现的基础。...

这只是个预告，耐心等待把。😀

起因 使 hugo 搭建博客已经有半年了，一直觉得用 markdown 才写博客才程序员应该有的范，所以看到 hugo 就觉得自己应该有一个这样的博客，后面就自己搭建起来。最近，写博客的频率越来越高，也越来越觉得交互对一个博客的重要性，于是集成评论系统的优先级变得越来越高。 最开始也想着直接集成现有的国内评论插件，后台喜欢的评论插件死的死，不死的也半死，于是把目光放在了 gitment 上，对于 gitment 的集成相对简单，其中也有一些小坑，于是便有了这篇文章,希望能够帮到有同样想法的小伙伴。 1. 简介 Gitment 是一款基于 GitHub Issues 的评论系统，支持在前端直接引入，不需要任何后端代码。可以在页面进行登录、查看、评论、点赞等操作，同时有完整的 Markdown / GFM 和代码高亮支持。尤为适合各种基于 GitHub Pages 的静态博客或项目页面Gitment是一款基于 GitHub Issues 的评论系统，支持在前端直接引入，不需要任何后端代码。可以在页面进行登录、查看、评论、点赞等操作，同时有完整的 Markdown / GFM 和代码高亮支持。尤为适合各种基于 GitHub Pages 的静态博客或项目页面。 2. 注册 到https://github.com/settings/applications/new ,中注册一个新的OAuth Application 其中 Authorization callback URL 写你的网站域名就可以了，例如我这里填写的是：http://www.artacode.com/ 注册完成后会得到 Client ID 和 Client Secret 两个值用于为们后面引入 gitment 3. 引入 增加评论开关： sudo vim $HUGO_PATH/config.toml ... [params] enableGitment = true ... //保存退出 在 themes/beautifulhugo/layouts/_default/single.html 文件中，合适的位置增加如下代码...

etcd入门系列 一. etcd在docker中的安装与使用 二. etcd 开启 https 三. 身份验证访问控制 四. 开启客户端证书访问 1. 生成客户端证书 生成client.json： $ cfssl print-defaults csr > client.json 编辑 client.json 的修改 CN 值为 cliet ... "CN": "client", "hosts": [""], ... 生成客户端证书 cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client client.json | cfssljson -bare client 将会得到如下文件 client-key.pem client.csr client.pem 2. 开启客户端证书检测 docker run -v /root/cfssl:/root/cfssl -p 2379:2379 --name etcd-net etcd /usr/local/bin/etcd -name etcd-net --client-cert-auth --trusted-ca-file=/root/cfssl/ca.pem --cert-file=/root/cfssl/server.pem --key-file=/root/cfssl/server-key.pem -advertise-client-urls https://0.0.0.0:2379 -listen-client-urls https://0.0.0.0:2379 --client-cert-auth:当这个选项被设置时，etcd 将为受信任CA签名的客户端证书检查所有的传入的 HTTPS 请求，不能提供有效客户端证书的请求将会失败。...

etcd入门系列 一. etcd在docker中的安装与使用 二. etcd 开启 https 三. 身份验证访问控制 四. 开启客户端证书访问 1. 简介 etcd 默认是没有开启访问控制的，如果我们开启外网访问的话就需要考虑访问控制的问题，etcd 提供了两种访问控制的方式： 基于身份验证的访问控制 基于证书的访问控制 这节主要是选择第一种方式，进行的讲解，由于之前文章中是采用http接口的方式通讯，为了更全面的了解 etcd 的使用，本节使用官方提供的 etcdctl 工具进行与服务器之间的通讯。 2. root 用户 root 是 etcd 的超级管理员，拥有 etcd 的所有权限，在开启角色认证之前为们必须要先建立好 root 用户。还需要注意的是 root 用户必须拥有 root 的角色,允许在 etcd 的所有操作. 3. root 角色 root 角色可以赋予任何用户，拥有 root 角色的用户有全局读写权限和集群身份验证配置权限，此外，还具有修改集群成员身份，碎片整理，建立快照等权限。 4. 用户操作 查看用户列表： $ etcdctl --ca-file /root/cfssl/ca.pem --endpoints https://192.168.3.3:2379 user list 创建用户： $ etcdctl --ca-file /root/cfssl/ca.pem --endpoints https://192.168.3.3:2379 user add user1 用户可以被赋予角色，也可以被撤销角色： #赋予权限 $ etcdctl --ca-file /root/cfssl/ca....