OnOff

之前利用点灯科技的库来使小爱同学控制LED的过程中，我们大略提到了一下MQTT的整体流程，由于其MQTT服务器是由点灯科技提供的，所以对其中的很多连接细节，我们并不知道，本节我们准备通过搭建本地的MQTT服务器，然后通过MQTT Client向MQTT服务器发送控制命令，来控制我们的LED灯。 首先，我们需要启动MQTT服务器，启动方式我们就不需要多说了，之前章节有讲解，启动完毕之后，其连接地址为：192.168.43.2:1883，切记连接地址不可写成127.0.0.1，否则无法连接成功。 然后，开始进行编码操作，具体编码内容如下： #include <ESP8266WiFi.h> #include <PubSubClient.h> #define JDQ 16 const char * MQTT_SERVER = " 192.168.43.2 " ; const int MQTT_PORT = 1883 ; const char * MQTT_USRNAME = " addmin " ; const char * MQTT_PASSWD = " public " ; const char * TOPIC = " home/devices/onoff/ " ; const char * CLIENT_ID = " scy-mqtt-client " ; //

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本篇讲 “故障自动维修流程”里 “环境初始化”这个环节。 初始化的问题—环境不一致 可能大家会觉得，环境初始化有什么好说的，不就是跑一堆设置系统参数的脚本么? 事实上，设置环境很容易，但是要保证环境设置正确会遇到很多问题。 环境不一致影响业务的case 先来看我们对业务sre 的访谈，因“环境设置不正确”导致业务受损的case有很多，如下所示， 因超线程未开启，导致服务在流量高峰时性能不足，产生请求拒绝 因QoS未设置，导致跨机房查询数据时，响应延迟飙高，大面积拖慢了了用户访问速度 因未设置ssd磁盘内核参数，导致磁盘处于低性能状态，影响业务读取速度 因网卡多队列未正确设置，导致单个cpu被打满，产生拒绝请求 因基础agent版本不一致，影响变更、数据配送任务，产生了脏数据 因core pattern 未正确设置，业务程序出core打满磁盘，拉长了止损时间 因环境缺失/版本不符导致业务程序依赖异常，产生请求拒绝, 如mysql/hadoop client 缺失, python/perl 版本过老 因内核网络、内存参数未正确设置，导致业务出现性能颠簸问题，产生间歇性请求拒绝，排查成本高 上述case，都是因部分机器环境未正确设置导致的，也就是机器环境存在“不一致”的情况。 环境不一致的原因 为什么会不一致