给你个最简单的算法 不反破解的 只防啥也不懂的
向
C:\Users\{Username}\AppData\Local\
首次启动，向目录写入一个文件
文件名为
register.db
文件内容为一个 50 位的随机数，两次 md5 后的字符串纯文本

然后 输入注册码的界面 显示一个机器码 这个机器码得出的方式为 那个文件的两次 md5 值，不是那个文件的内容，机器码为 32 位的 16 进制字符串，也可以将其转为 10 进制变为一个长数字

然后给你机器码 你用算法算成注册码给用户 用户填入得出授权是否有效


注册码生成算法为
预设到期日期假如为 20200901，转成字符串，拆解成 8 个字符 记为 A B C D E F G H

机器码进行 sha1 得出一个十六进制字符串，拆解成 char 数组，按以下索引顺序重新组合成一个字符串 其中 ABCDEFGH 是上文的字符

7,29,A,4,0,B,12,2,C,1,14,D,9,32,E,17,4,F,19,33,G,13,24,H,5,27,30,20


得到一个 28 位的字符串

然后将这个 28 位的字符串进行 SHA1 hash，得到一个字符串，取其中的第 9 位开始，连续取 4 位，字符串，作为校验码


然后将前面的 28 位字符串和这四位校验码进行拼接成一个字符串，作为注册码。


在离线 APP 验证时，先通过后四位计算注册码合法性

然后用机器码计算出 hash 判断前面的合法性，如果完全合法，提取出 ABCDEFGH 拼接成到期日期

@askcto #18
我并不是想让你给钱啥的，这是针对你产品模式的一个提问。

你没影响力没圈子在不砸钱的前提下，还没法通过给优秀知识来源付费，靠什么搞用户？
没有用户，这就是瞎折腾。
V2 里有能力做这么个东西的人能占 30%，并不是他们没情怀或者什么的。

当然，话说重一点你别介意，天天没事搞这些看起来很自我安慰的真心没啥前途的项目，可能也是你落魄的重要原因

请问，我去给人解答问题，给钱么？

"/0 的情况一般统一写成 0.0.0.0/0 表示为任意 IP 。因为前面写任意 IP 在这里都没有意义了。"

说明你对 IP 地址 子网掩码的合并机制一无所知 而且连书都没看过……

基于显存容量选择……

@qiuai #35
现在好了。
我发帖那会儿 上传 500M 以上 1G 以下的文件，就反复这个错误。

@594duck #92
不是 CDN 啊 啥场景 这些机器的 SLA 可用性都高于四个 9

而且，大量的业务可用性是用 HA 机制保障的

我不知道你经手管理过多少物理环境在标准内的大批量设备
硬件故障率，不含硬盘，远没有你想象的那么高

@qiuai #32
找了个大文件上传测试一下速度和稳定性 总是失败……
传完以后 什么移动到 storage node 然后就报错

https://i.imgur.com/nxktVZL.png

被信安系统拦截了
十有八九是未备案域名或者没在阿里云做接入

one drive E5
5TB 可扩容 25T 足够了

@privil #85
如果不按 ESC 中断自检层 MEMTEST 的话，要很久很久很久很久
如果按 ESC 中断自检层 MEMTEST，做普通内存自检，大概 7-30 分钟，时间比较不定，可能是某些内存有响应不好的问题
这机器基本不重启的……


@594duck #83
公司是数据中心啊
都是按需买的
机房里扣除形象项目 政府项目啥的 90%是垃圾服务器在跑应用……


@594duck #83
大数据团队？不存在的。这只是我的一个自己的小私活而已。

备份方案？应用层备份。每时每刻分布式备份，以及后半夜备份。因为应用特性导致非工作时间的直接操作性业务压力极低极低，不是关闭服务，是没啥人用了，加班的以及圈子开源部分测试 /研发团队在实际使用。后半夜有 2 小时，所有分布式任务全部停止，只保留对零星用户的服务，同时 MYSQLDUMP

@594duck #89
找不出洋垃圾？我机房现在 E5 二代 /一代的服务器大概有六千多台，每个月还新采购 100 台左右

腾讯什么的 CDN 转包那边甚至全是 1366 平台居多，2019 年 6 月份以后新增加节点才大肆上 2011 的机器

1366 的机器而论，大部分出厂日期是 2009-2010 年，我这边 2016-2017 左右采垃圾然后用于生产环境，这批机器，基本到 2020 年左右才开始逐渐影响应用的故障率稍微多一点，所以开始演进往 2011 平台走，现在新采购以 2011 为主，偶尔赶上大批量极其便宜的 1366 还会搞一些，反正自己应用很多用得上的地方

至于你说的寿命，你对硬件寿命真的，一无所知……而且你对捡垃圾这个行业也一无所知。
用 E5 二代平台的原因，主要是内存便宜。1.5TB 是这一代的内存极限，低于这个的也满地，因为廉价内存而已。
DELL 的十三代平台，垃圾渠道已经开始流通了，最大的阻碍是 D4REG 和 D4LRDIMM 内存太贵而已


比如吧 你现在天天看的国内大视频网站，他们最大的分发是廉价采购的多重转包的资源回收，这部分，基本全是在用 1366 的机器在跑（因为成本低）。


比如，我现在机房有一个小项目，某知名视频站的大概 80Gbps 的分发，16 个机柜，每个机柜 12 台服务器，共计 192 台服务器。
因为这个项目是最近谈的，直接从备用机里提了 192 台 R720xd，客户对 CPU 和内存要求不高，所以上的 2640v2 双路，64G/128G 内存，每台机器 12 块 2TB 垃圾 SSD+魔改 H710 为 HBA 。没几个成本。


如果这个项目要是 2018 年接的，那么基本上当时就是配 R510/C2100 这种机器+双路 L5640+48GRAM+2TB*10 了

你想多了
云计算论坛最后结果就是满屏卖梯子 VPS 的和发 aliyun 腾讯云返利连接的

存储配置是 数据盘 8 NVME 盘 RAID10 高性能的数据中心级 NVME
机器是洋垃圾二代 E5 双路，配 1.5TB RAM

@594duck #78

自己拼的垃圾服务器 从我机房堆里翻出来的

读写密集的数据库是全 int 表，不存在字符串，字段数极多

主要业务场景是 INSERT 进来，受限于数据不是本机软件生成，一个 INSERT 只有一条记录一次 commit，所以写查询比 delete 查询数量多，delete 都是按有效期一次删一片

基本 insert 进来的数据有效期是一天，大量分表，没分库。分表依据是基于应用逻辑的，而不是基于数据的算法分表，所
以表行数不均匀，比较少的表几十万行，比较多的 800 万行左右。

数据每天增加的量大致差不多，insert 时间不分散到每个小时，而是按一定逻辑分散。

insert 进来的数据要保存 72 天，之后删除，删旧的，保持数据库内基本保存 73 天的有效数据

删除是我自己写的分布式删除脚本，分散到一天 24 小时除了备份数据时间段的每时每刻

update 是表内数据的主要逻辑，基本主要操作都是 update 一条表记录为一个临时状态值占用，而不是用事务行锁。

我这里最暴躁的一台 MYSQL，单机……

https://imgur.com/Zu24WLu

@594duck #73
你这个归纳显然是有问题的
不信你弄个百万行的表试试……

面向 IPO 求职