nikandaoleshenme

@dandelion911
现在是 2%的人拥有 120%的财富，剩下 98%的人负债 20%

万物皆对象？

换个稳定的主机，比如这台 uptime 14:12:31 up 398 days, 3:59，近 400 天，没停机，上面的服务也没有宕机

服务器没有你想的那么重要，当然也没有你想的那么弱不禁风，说故障就故障了

初次下载完后，将生成的新文件上传到 OSS，下次碰到相同的请求重定向到 OSS 上去

0，自己动手写一个
1，日志有明确的格式
2，编写一个程序（ shell 、py 、亦或你最拿手的语言 java 、go ），定时读取日志，然后解析格式（解析规则取决于日志格式），入库
3，库可以是 es，甚至 mysql 、 建议文档数据库 mongodb，简单易用，方便后续的聚合查询
4，工作量：一个人全心投入，一个下午即可出一个 简版来
5，注意事项：日志解析需要细心，大文本读取策略，内存溢出，
6，开始行动 或者 pass

https://github.com/GZK0329/private_demos/blob/master/捕获 021.JPG

把图片放出来撒，私有的怎么看

1，数据接收方决定了服务上限，
2，我也有过与硬件设备通讯的场景，也是带着互联网程序开发的思想去开发硬件，也碰到了这些问题，慢，慢，慢，甚至还得程序主动休眠停顿一下才继续处理，后来想明白了，硬件设备也是微型计算机，它的计算能力只有那么多，出厂就设定好了，
3，后面竟然联想到了人生😂......

1，序列化方案取决于业务场景，通常的文本数据传输使用 json 格式，不能使用 json 格式的就需要私有协议和自定义序列化规则

2，对于计算机来说，时间只是一个数字，所以存储、传输、计算 时间操作最优解肯定是数字格式，但对于自然人来说就不是了，建议：若程序服务的用户都在一个 行政时区 内，那使用当地时区时间格式无疑是最为方便的，对于程序也是一致的。若不是，使用数字格式最为通用，最终的时间格式展示只需要转换为当地时间即可

PS C:\Users\hp> ping github.com

正在 Ping github.com [13.250.177.223] 具有 32 字节的数据:
请求超时。
请求超时。
请求超时。
请求超时。

13.250.177.223 的 Ping 统计信息:
数据包: 已发送 = 4，已接收 = 0，丢失 = 4 (100% 丢失)，
PS C:\Users\hp> ping gitee.com

正在 Ping 3074413c.dayugslb.com [180.97.125.228] 具有 32 字节的数据:
来自 180.97.125.228 的回复: 字节=32 时间=24ms TTL=43
来自 180.97.125.228 的回复: 字节=32 时间=25ms TTL=43
来自 180.97.125.228 的回复: 字节=32 时间=26ms TTL=43
来自 180.97.125.228 的回复: 字节=32 时间=24ms TTL=43

180.97.125.228 的 Ping 统计信息:
数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 24ms，最长 = 26ms，平均 = 24ms