nsq

以下配置只针对nsqadmin v1.1.0 (built w/go1.10.3)版本 # # The default server # server { listen 80 default_server; listen [::]:80 default_server; server_name _; root /usr/share/nginx/html; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location /nsq/ { auth_basic "NSQ Administrator's Area"; auth_basic_user_file /root/nsq/bin/.htpasswd; proxy_pass http://127.0.0.1:4171/; # proxy_redirect default; proxy_redirect http://127.0.0.1:4171/ /nsq/; proxy_set_header Accept-Encoding ""; # no compression allowed or next won't work sub_filter_types *; sub_filter '/static

如何快速获得高并发编程经验？PCC性能挑战赛作品简介及源代码 PCC 是 Performance Challenge Championship （性能挑战杯）的缩写，是高可用架构后花园会员在线上组织的一个活动，由于反响热烈，考虑到线下进行可以更好的加深对高并发编程的理解，于是高可用架构在 3 月组织了本次 PCC 活动。 对于工程师来说，参加 PCC 编程挑战赛的部分意义： 体验完成一个技术小目标。高性能系统如何实现应当是每个工程师需要走的路。 学习优秀的架构方法，隔壁老王用的设计思想，可能你坐在办公室永远也无法想到。 有经验评委的点评，了解真实环境的高并发系统的追求目标。 类似主题、有同样级别参赛队员及评委参加的编程活动，可能仅此一次。 比赛方法说明 实现类似 facebook 中的 like 功能，需要： 可以对一个对象（一条feed、文章、或者url）进行 like 操作，禁止 like 两次，第二次 like 返回错误码 有 isLike 接口，返回参数指定的对象有没有被当前用户 like 过 需要看到一个对象的 like 计数 可以看到一个对象的 like 用户列表（类似 QQ 空间）； 上述列表加分项：Like优先显示我的好友列表(social list)。 数据量：每天新增的 like 对象数为 1 千万，每秒 like 计数器查询量为 30 万次 / 秒。 比赛盛况

我关于Go语言的博客原本发布于我的个人网站: wwww.liwenzhou.com 。 但是被某些人抄怕了，没办法只好搬运到博客园。 我的Go语言学习之路 《Go语言学习之路》博客目录。 2015年底我因为工作原因接触到了Go语言，那时网上关于Go语言的学习资料不多，好在一直坚持到现在。我把自己学习Go语言的笔记都整理到这里，希望能给Go社区的发展出一点绵薄之力，帮助更多的人加入Gopher大家庭。 Go语言介绍 为什么你应该学习Go语言？ → B站视频链接 开发环境准备 从零开始搭建Go语言开发环境 → B站视频链接 VS Code配置Go语言开发环境 → B站视频链接 Go语言基础 Go语言基础之变量和常量 → B站视频链接 Go语言基础之基本数据类型 → B站视频链接 Go语言基础之运算符 → B站视频链接 Go语言基础之流程控制 → B站视频链接 Go语言基础之数组 → B站视频链接 Go语言基础之切片 → B站视频链接 Go语言基础之map → B站视频链接 Go语言基础之函数 B站视频01函数部分 B站视频02匿名函数和闭包部分 Go语言基础之指针 → B站视频链接 Go语言基础之结构体 B站视频01自定义类型和类型别名 B站视频02结构体定义与实例化 B站视频03方法和接收者 B站视频04结构体嵌套 B站视频05结构体字段可见性和JSON

Redis使用规范 在公司项目中，redis属于高频使用，在使用中，我们遇到了各种各样的redis问题，于是针对自身情况梳理了一个redis使用规范。 一、键名设计 1、key名设计 禁止包含特殊字符(比如空格、换行、单双引号以及其他转义字符) 建议以业务名为前缀，以冒号分割来构造一定规则的key名(比如业务名:表名:id) 比如:teach:leeson_id:21 控制key的长度 key太长量一大起来就会非常占用内存 2、value设计 拒绝大key操作 禁用超过10K的string大key(虽然redis支持512MB大小的string)，如果1mb的key每秒重复写入10次，就会导致写入网络IO达10MB。 错误示范：直接将laravel的整个模型或者对象当成value存储 设计key时使用合适的数据类型(在资源利用和性能之间作平衡) 错误示范：一个普通字符串弄成hash类型进行存储 一定要控制key的生命周期 错误示范：key设置为永不过期 控制value长度 比如string类型，如果value为'8个字节的长整型'则内部使用int类型，如果value为'小于等于39个字节的字符串'则内部使用embstr类型，如果value为'大于39个字节的字符串'则内部使用raw类型。这样能很好的利用redis的性能。 数据按需存储 不需要的数据千万不要存储在redis

　　 　　list类型是简单的字符串列表，按照插入顺序排序。每个列表最多可以存储 2 32 - 1 个元素（40多亿） ，list类型主要有以下应用场景。。 　　1. 消息队列 　　list类型的lpop和rpush（或者反过来，lpush和rpop）能实现队列的功能，故而可以用Redis的list类型实现简单的点对点的消息队列。不过我不推荐在实战中这么使用，因为现在已经有Kafka、NSQ、RabbitMQ等成熟的消息队列了，它们的功能已经很完善了，除非是为了更深入地理解消息队列，不然我觉得没必要去重复造轮子。 　　2. 排行榜 　　list类型的lrange命令可以分页查看队列中的数据。可将每隔一段时间计算一次的排行榜存储在list类型中，如京东每日的手机销量排行、学校每次月考学生的成绩排名、斗鱼年终盛典主播排名等，下图是酷狗音乐“K歌擂台赛”的昨日打擂金曲排行榜，每日计算一次，存储在list类型中，接口访问时，通过page和size分页获取打擂金曲。（打个小广告，酷狗音乐“K歌擂台赛”每天都能产生一批优质翻唱作品，对普通人优质歌声有兴趣的朋友不妨来听听）。 　　 　　 　　但是，并不是所有的排行榜都能用list类型实现，只有定时计算的排行榜才适合使用list类型存储，与定时计算的排行榜相对应的是实时计算的排行榜，list类型不能支持实时计算的排行榜

故障和问题是系统设计与开发的指示灯。 引言 俗话说：好的战士，是从枪林弹雨中打出来的。好的工程师，是从沼泥坑洞中踩出来的。 在平常的开发中，人很难主动去思考深入的东西。故障，层出不穷的问题，是开发人员想要回避的却始终难以回避的事情。从正面的角度来看，错误是人类进步的阶梯。故而，每一个显现的故障和问题，也能引导人更加深入地理解系统的运行，思考一些平时很少思考的东西，是很有益的礼物。在有赞的四年里，我踩过不少坑，总结出来，期望对后来者有所启发。 导图 坑位及启示 踩坑不是目标，从踩过的坑中汲取足够的经验教训才划算。如何分析一个坑位呢 ？首先，应当从逻辑上严密地论证为什么会出现这个问题，其严密性如 1+1=2 一样无疑议；其次，带来的启示和指导是怎样的，如何去防范类似的问题。 名字覆盖出错 或许出于对同行的莫可名状的“不满”情绪，程序猿看到不太顺眼的地方，总有一种想要改掉它的冲动。但人在采取行动之前，又容易缺乏思考。因此，冲动常常招致小小的惩罚。 譬如说，我刚接手订单导出。看到报表文件名是：kdt_8fb888f9c9fad7840190d9d1531dddfc.csv 。 心想，这后面一串可真难看，商家也看不懂。为啥不改成更友好的形式呢 ？ 于是，我修改成了 kdt_2020-05-02-13-49-12.csv 。 猜猜看，发生了什么 ？ 不同商家的报表发生了覆盖

故障和问题是系统设计与开发的指示灯。 引言 俗话说：好的战士，是从枪林弹雨中打出来的。好的工程师，是从沼泥坑洞中踩出来的。 在平常的开发中，人很难主动去思考深入的东西。故障，层出不穷的问题，是开发人员想要回避的却始终难以回避的事情。从正面的角度来看，错误是人类进步的阶梯。故而，每一个显现的故障和问题，也能引导人更加深入地理解系统的运行，思考一些平时很少思考的东西，是很有益的礼物。在有赞的四年里，我踩过不少坑，总结出来，期望对后来者有所启发。 导图 坑位及启示 踩坑不是目标，从踩过的坑中汲取足够的经验教训才划算。如何分析一个坑位呢 ？首先，应当从逻辑上严密地论证为什么会出现这个问题，其严密性如 1+1=2 一样无疑议；其次，带来的启示和指导是怎样的，如何去防范类似的问题。 名字覆盖出错 或许出于对同行的莫可名状的“不满”情绪，程序猿看到不太顺眼的地方，总有一种想要改掉它的冲动。但人在采取行动之前，又容易缺乏思考。因此，冲动常常招致小小的惩罚。 譬如说，我刚接手订单导出。看到报表文件名是：kdt_8fb888f9c9fad7840190d9d1531dddfc.csv 。 心想，这后面一串可真难看，商家也看不懂。为啥不改成更友好的形式呢 ？ 于是，我修改成了 kdt_2020-05-02-13-49-12.csv 。 猜猜看，发生了什么 ？ 不同商家的报表发生了覆盖

【推荐阅读】微服务还能火多久？>>> 在阅读 nsq 源码的时候，发现nsq使用 TOML 配置文件规范。顺带翻译了大部分。采用英中文混排的方式，这样比较容易理解。 toml-lang/toml TOML Tom's Obvious, Minimal Language. 直观的，最小化的语言 By Tom Preston-Werner. Latest tagged version: v0.2.0 . Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly. Objectives TOML aims to be a minimal configuration file format that's easy to read due to obvious semantics. TOML is designed to map unambiguously to a hash table. TOML should be easy to parse into data structures in a wide variety of languages. 最小化配置文件格式，直观的语意，很容易阅读

简介 伙计们，请搬好小板凳坐好，下面将是一段漫长的旅程，期望你能够乐在其中。 我将基于 Kubernetes [1] 部署一个分布式应用。我曾试图编写一个尽可能真实的应用，但由于时间和精力有限，最终砍掉了很多细节。 我将聚焦 Kubernetes 及其部署。 让我们开始吧。 应用 TL;DR 该应用本身由 6 个组件构成。代码可以从如下链接中找到： Kubenetes 集群示例 [2]。 这是一个人脸识别服务，通过比较已知个人的图片，识别给定图片对应的个人。前端页面用表格形式简要的展示图片及对应的个人。具体而言，向 接收器 [3] 发送请求，请求包含指向一个图片的链接。图片可以位于任何位置。接受器将图片地址存储到数据库 (MySQL) 中，然后向队列发送处理请求，请求中包含已保存图片的 ID。这里我们使用 NSQ [4] 建立队列。 图片处理 [5] 服务一直监听处理请求队列，从中获取任务。处理过程包括如下几步：获取图片 ID，读取图片，通过 gRPC [6] 将图片路径发送至 Python 编写的 人脸识别 [7] 后端。如果识别成功，后端给出图片对应个人的名字。图片处理器进而根据个人 ID 更新图片记录，将其标记为处理成功。如果识别不成功，图片被标记为待解决。如果图片识别过程中出现错误，图片被标记为失败。 标记为失败的图片可以通过计划任务等方式进行重试。 那么具体是如何工作的呢