EvenviInfluxDB Cloud和InfluxDB OSS的区别
Publish: October 26, 2020 Category: 运维 No Comments
InfluxDB Cloud 2.0与InfluxDB OSS 2.0兼容，在功能上也兼容。InfluxDB OSS 2.0和InfluxDB Cloud 2.0的主要区别是：
- 用于指定目标收集数据的InfluxDB scraper在InfluxDB Cloud中不可用。
- InfluxDB cloud实例目前仅限于一个组织。
Ubuntu下安装时序数据库InfluxDB安装可视化工具Chronograf
Publish: October 16, 2020 Category: 运维 No Comments
InfluxBD所有下载预览
https://portal.influxdata.com/downloads/
ubuntu下安装influxdb
wget https://dl.influxdata.com/influxdb/releases/influxdb_1.8.3_amd64.deb dpkg -i influxdb_1.8.3_amd64.deb
启动和关闭
service influxdb startservice influxdb stop
默认情况下回占用8088和8086两个端口，很多人的服务器nginx可能回配置这个端口导致服务启动失败，注意下这种情况。
配置和数据目录
数据文件夹：/var/lib/influxdb data 存放最终存储的数据，文件以.tsm结尾 meta 存放数据库元数据 wal 存放预写日志文件 配置文件： /etc/influxdb/influxdb.conf
PHP的InfluxDB客户端库使用
Publish: October 16, 2020 Category: 代码分享 No Comments
这是一个influxdb的1.新版本客户端
https://github.com/influxdata/influxdb-php
如果使用的是2.x版本，请使用找个客户端
https://github.com/influxdata/influxdb-client-php
概览
一个易于使用的库，用于将inflexdb与PHP结合使用。由 @thecodeassassin, @gianarb. 维护。inflexdbphp库是为了拥有python influxdb客户机的php端口而创建的。这样，不同编程语言之间将有一个通用的抽象库。
安装
可以使用composer完成安装：
$ composer require influxdb/influxdb-php
PHP 5.3 和 PHP 5.4 用户请zhu'yi
如果使用php5.3和php5.4，0.1.x版本仍然受支持（bug修复和新版本修复）。0.1.x分支将在php5.3和php5.4上运行，但不包含1.0.0版本所具有的所有特性，例如UDP支持。
开始使用
初始化一个新的客户端对象
$client = new InfluxDB\Client($host, $port);
这将创建一个新的客户机对象，您可以使用它来读写InfluxDB的点。还可以从DSN（数据源名称）创建客户端：
// 直接获取数据库句柄
$database = InfluxDB\Client::fromDSN(sprintf('influxdb://user:pass@%s:%s/%s', $host, $port, $dbname));
// 使用客户端检索其他数据库
$client = $database->getClient();
重要提示：当使用DSN时，不要忘记urlencode（）password（和username），尤其是当它包含非字母数字字符时。不这样做可能会引发异常。
MQTT 5.0到期消息Message Expiry
Publish: October 16, 2020 Category: 编程 No Comments
MQTT 5.0规范中有一个整洁的小功能，称为消息过期（或消息过期间隔）。
互联网上已经对此进行了多次解释。它允许发布者在其发送的任何消息中添加有效期限。有时候，我们对功能有误解。误解是MQTT 3.1.1协议缺少Message Expiry，而现在它已存在于5.0中，它将取代并替换保留的消息和其他持久会话功能。好吧，没那么快。
您很可能会从传统企业消息传递系统中了解消息过期（或TTL，生存时间）。规范的示例在这里：消息过期模式。
传统消息过期模式与MQTT
此模式的应用程序主要是这样的：
- 首先，您希望使用者在特定时间范围内处理作业（应用程序消息）。
- 其次，您希望将应用程序消息转发到dead lettering队列，以防使用者无法及时处理它。从dead lettering队列中，您的后端系统可以处理该消息并重新触发作业或任何其他需要的操作。
现在，MQTT没有队列概念，当然也没有dead lettering队列概念！因此，我们从一开始就面临着截然不同的情况。您不能只配置dead lettering队列（或dead lettering主题）。顺便说一下，这也是原因，MQTT与其他系统一样，除了消息TTL之外没有“队列TTL”。 （请注意，它具有Session Expiry，这又是完全不同的东西）。
MQTT v3.1.1中用户名、密码、客户端ID的最大长度
Publish: October 16, 2020 Category: 编程 No Comments
在连接包中
MQTT CONNECT控制数据包始终包含有效负载。它是建立连接后客户端必须发送给服务器的第一个数据包。
它只能由客户端发送一次，如果发送了第二个连接包，服务器（代理）必须将其作为协议冲突处理并断开客户端连接。
有效载荷可能包含几个不同的字段：
唯一客户端标识符（clientid）–始终存在
- topic
- message
- 用户名
- 密码（也需要用户名！）
clientid是必需的，其他字段是可选的。可选字段的存在由标头中的标志确定。
限制
以下是合规broker应支持的限额：
clientid:23个UTF-8编码字节
用户名编码后最大655535字节（UTF-8编码）
密码：0到65535字节的二进制数据
消息限制大小：268435455字节
满足MQTT v3.1.1规范的任何代理都需要支持客户机id的以下字符：
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
broker可以选择支持其他字符和更长的客户机ID。
23个字就够了。记住，这些不是位，而是字符。例如，如果使用base58编码，则得到58^23个组合~3,62E+40~ 362112794667800000000000000000000000000个组合。如果你没有，那就更糟了。
broker可以选择支持长度为零字节的clientid。在这种情况下，代理必须为客户机分配一个唯一的clientid。并非所broker都支持这一点（根据规范“可选”）。
用户名必须是UTF-8编码字符串。密码可以是二进制数据。
消息也可以是二进制数据。