时间戳

MQTT基础知识 MQTT是一种轻量级的发布 - 订阅消息传递协议，可能使其最适合各种物联网设备。您可以在此处找到有关MQTT的更多信息。 ThingsBoard服务器节点充当MQTT Broker，支持QoS级别0（最多一次）和1（至少一次）以及一组预定义主题。 客户端库设置 您可以在Web上找到大量MQTT客户端库。本文中的示例将基于Mosquitto,MQTT.js和Paho,要设置其中一个工具。 客户端库设置 您可以在Web上找到大量MQTT客户端库。本文中的示例将基于Mosquitto,MQTT.js和Paho,要设置其中一个工具。 键值格式 默认情况下，ThingsBoard支持JSON中的键值内容。Key始终是一个字符串，而value可以是string，boolean，double或long。也可以使用自定义二进制格式或某些序列化框架。有关详细信息，请参阅物模型。例如： {"stringKey":"value1", "booleanKey":true, "doubleKey":42.0, "longKey":73} 遥测上传API 为了将遥测数据发布到ThingsBoard服务器节点，请将PUBLISH消息发送到以下主题： v1/devices/me/telemetry 最简单的支持数据格式是： {"key1":"value1", "key2":"value2"}

一、前言 方便要开发微信小程序的朋友们，可以快速将服务搭建起来，不要把时间浪费在服务的搭建上，专心写我们的业务代码。 你需要了解的知识： 1.微信小程序大概的开发流程 2.注册小程序（个人测试账号） 3.服务器的配置 4.内网穿透（我用的是花生壳） 5.小程序开发文档先大概看一遍 废话不多说了，你懂得，直接讲重点… 源码下载地址（服务端）： 下载 源码下载地址（小程序demo）： 下载 二、脚手架预览 2.1 项目结构 2.2 小程序demo 整体小程序上就实现上面这些功能。 三、怎么快速把项目跑起来（服务端） 3.1 修改配置 application.xml logging: level: org.springframework.web: info com.lxh.miniapp: debug cn.binarywang.wx.miniapp: debug server: port: 80 servlet: context-path: / wx: miniapp: configs: - appid: wx2d88824e64axxxxxx secret: f1e1d8785bfbe9d36d538xxxxxxxxx token: miniapp aesKey: K1ewVmypZKPTl2BIB8ySTY9C5rpteZxxxxxxxxx msgDataFormat: JSON

　　最近在操作项目的时候碰到一个Unix时间戳转换的问题。 "date_time":1393031347 这个是什么，你知道吗？如果你对Unix时间戳了解的话一眼就看出来。但我们本着科普的理念稍微介绍一下，大神请飘过。 　　看到 date_time ，我们第一反应就是日期时间，但是后面的一串数字什么意思天才晓得！我们是好学的孩子，不能做那么不负责的事情，不懂就找度娘，虽然度娘已经出走了。搜索了一下，大部分结果是说用不同编程语言进行datetime转换，比如java、perl、php等，虽然略知一二，但要写一个时间戳转换程序尔等小民高不可攀，而且时间成本太高了。 　　继续search，总算知道了那串数字是unix时间戳。现在局势有些好转了，知其然不知其所以然那是不可能的，通过你的努力"所以然"很快就要显现人间了。很多站长工具都有 Unix时间戳(Unix timestamp)转换工具 ，但是那些只能一次转换一个。一大列时间戳够你整一个月的。 　　工欲善其事必先利其器！Excel批量操作数据是个不错的选择。那就开工了！Excel默认不支持Unix格式时间戳，但前辈们早就为我们考虑到了。可以用以下公式将时间戳转换成Excel格式的时间：=(x+8*3600)/86400+70*365+19，如果不行换成=(x+8*3600)/86400+66*365+19 　　怎么样

一、ObjectId的组成 首先通过终端命令行，向mongodb的collection中插入一条不带“_id”的记录。然后，通过查询刚插入的数据，发现自动生成了一个objectId “5e4fa350b636f733a15d6f62”这个24位的字符串，虽然看起来很长，也很难理解，但实际上它是由一组十六进制的字符构成，每个字节两位的十六进制数字，总共用了12字节的存储空间。相比MYSQL int类型的4个字节，MongoDB确实多出了很多字节。不过按照现在的存储设备，多出来的字节应该不会成为什么瓶颈。不过MongoDB的这种设计，体现着空间换时间的思想。 ObjectId的官方规范 1)Time 时间戳。将刚才生成的objectid的前4位进行提取“5e4fa350”，然后按照十六进制转为十进制，变为“1582277456”，这个数字就是一个时间戳。通过时间戳的转换，就成了易看清的时间格式2020-02-21 17:30:56， 2)Machine 机器。接下来的三个十六进制就是“b636f7”，这三个是所在主机的唯一标识符，一般是机器主机名的散列值，这样就确保了不同主机生成不同的机器hash值，确保在分布式中不造成冲突，这也就是在同一台机器生成的objectId中间的字符串都是一模一样的原因。 3)PID 进程ID

Apache Flink（下简称Flink）项目是大数据处理领域最近冉冉升起的一颗新星，其不同于其他大数据项目的诸多特性吸引了越来越多人的关注。本文将深入分析Flink的一些关键技术与特性，希望能够帮助读者对Flink有更加深入的了解，对其他大数据系统开发者也能有所裨益。本文假设读者已对MapReduce、Spark及Storm等大数据处理框架有所了解，同时熟悉流处理与批处理的基本概念。 Flink简介 Flink核心是一个流式的数据流执行引擎，其针对数据流的分布式计算提供了数据分布、数据通信以及容错机制等功能。基于流执行引擎，Flink提供了诸多更高抽象层的API以便用户编写分布式任务： DataSet API， 对静态数据进行批处理操作，将静态数据抽象成分布式的数据集，用户可以方便地使用Flink提供的各种操作符对分布式数据集进行处理，支持Java、Scala和Python。 DataStream API，对数据流进行流处理操作，将流式的数据抽象成分布式的数据流，用户可以方便地对分布式数据流进行各种操作，支持Java和Scala。 Table API，对结构化数据进行查询操作，将结构化数据抽象成关系表，并通过类SQL的DSL对关系表进行各种查询操作，支持Java和Scala。 此外，Flink还针对特定的应用领域提供了领域库，例如： Flink ML，Flink的机器学习库

文章目录 之前的几篇文章已经分别理解了： 如何定义自己的数据集 如何训练自己的网络 dataset和model是怎么构造的 本文就再详细的看一下，在构造好了dataset和model是如何训练的。从tools/train.py中 # mmdetection/tools/train.py train_detector ( model , datasets , cfg , distributed = distributed , validate = args . validate , timestamp = timestamp , meta = meta ) 可以进入在mmdet/apis/train.py中 # mmdetection/mmdet/apis/train.py runner = Runner ( model , batch_processor , optimizer , cfg . work_dir , logger = logger , meta = meta ) . . . runner . run ( data_loaders , cfg . workflow , cfg . total_epochs ) 再查看runner，可以看到， # mmcv/runner/runner.py class Runner : def train ( self , data

一、 表设计规范 库名、表名、字段名必须使用小写字母，“_”分割。 库名、表名、字段名必须不超过12个字符。 库名、表名、字段名见名知意,建议使用名词而不是动词。 建议使用InnoDB存储引擎。 存储精确浮点数必须使用DECIMAL替代FLOAT和DOUBLE。 建议使用UNSIGNED存储非负数值。 建议使用INT UNSIGNED存储IPV4。 整形定义中不添加长度，比如使用INT，而不是INT(4)。 使用短数据类型，比如取值范围为0-80时，使用TINYINT UNSIGNED。 不建议使用ENUM类型，使用TINYINT来代替。 尽可能不使用TEXT、BLOB类型。 VARCHAR(N)，N表示的是字符数不是字节数，比如VARCHAR(255)，可以最大可存储255个汉字，需要根据实际的宽度来选择N。 VARCHAR(N)，N尽可能小，因为MySQL一个表中所有的VARCHAR字段最大长度是65535个字节，进行排序和创建临时表一类的内存操作时，会使用N的长度申请内存。 表字符集选择UTF8。 使用VARBINARY存储变长字符串。 存储年使用YEAR类型。 存储日期使用DATE类型。 存储时间（精确到秒）建议使用TIMESTAMP类型，因为TIMESTAMP使用4字节，DATETIME使用8个字节。 建议字段定义为NOT NULL。 将过大字段拆分到其他表中。

package main import( "fmt" "time" ) func main() { datetime := "2015-01-01 00:00:00" //待转化为时间戳的字符串 //日期转化为时间戳 timeLayout := "2006-01-02 15:04:05" //转化所需模板 loc, _ := time.LoadLocation("Local") //获取时区 tmp, _ := time.ParseInLocation(timeLayout, datetime, loc) timestamp := tmp.Unix() //转化为时间戳 类型是int64 fmt.Println(timestamp) //时间戳转化为日期 datetime = time.Unix(timestamp, 0).Format(timeLayout) fmt.Println(datetime) } 来源： https://www.cnblogs.com/yxhblogs/p/9020947.html

最近写了一个 API Token 的校验服务，想要增加时效性控制，比如一个 API，超过一段时间（比如 10s）之后，用同样的参数再请求就会被服务器禁掉，无法获取正常数据，这样可以保证数据的安全。 怎么增加时效性控制呢？加一个时间的信息就好了，我们可以把时间信息包含在一个 API URL 的额外的参数 token 里面。比如最简单的，把前端获取的时间戳进行 Base64 编码之后作为 token，这个 token 会传递给后端，后端会对获取到的 token 进行解码，对获取到的时间戳进行校验，如果 Token 里面的时间戳和 Server 端的时间戳相差不超过一定的时间阈值（比如 10s），那就正常返回结果。如果超过一定的时间，服务器就直接返回 401 状态码，不会返回正常数据，这样可以保证接口的实时性，进一步保证安全。 但是现在遇到了一个问题，我一开始把二者的时间差阈值设置成了 10 秒，在本地测试没有问题，完全 OK，接口可以正常获取数据。怪的问题来了，我把项目部署到服务器上，发现怎么着都不行，一直返回 401 状态码。经过调试发现是前后端在同一时间获取到的时间戳是不一样的，足足相差了有 16 秒，服务器获取的时间戳比客户端慢了 16s，这导致在同一时刻二者并不能达到阈值条件，导致接口一直不能获取正常数据。 这到底是是为什么？为啥部署到服务器上之后，时间戳差别这么大呢？ 原因

一、什么是关联 关联（correlation）：脚本回放过程中，客户端发出请求，通过关联函数所定义的左右边界值（也就是关联规则），在服务器所响应的内容中查找，得到相应的值，已变量的形式替换录制时的静态值，从而向服务器发出正确的请求，这种动态获得服务器响应内容的方法被称作关联。也是把脚本中某些写死的数据，转变成动态的数据。 什么内容需要关联：当脚本中的数据每次回放都发生变化时，并且这个动态数据在后面的请求中需要发送给服务器，那么这个内容需要通过关联来询问服务器，获得该数据的变化结果。例如： 1.登录字符串。带有会话 ID 或时间戳等动态数据的登录字符串。 2.日期/时间戳。使用日期或时间戳或者其他用户凭据的任意字符串。 3.常见前缀。后跟字符串的常见前缀，如 SessionID 或 CustomerID 二、web_reg_save_param函数说明 语法： int web_reg_save_param(const char *ParamName, <list of Attributes>, LAST); 参数说明: · ParamName: 存放得到的动态内容的参数名称 · list of Attributes: 其它属性，包括：Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, SaveLen