真服了你们了 这么简单一个算法 自己随便折腾下就知道了

这玩意你完全可以根据自己需要改造一下

Y9000X 专门不带显卡的

请使用外接显卡..

如果你觉得外接显卡划不来,真不要买这款

笔记本连 cpu 的热都散步过来,还带显卡想要性能必须做成砖头

那些不是砖头的带显卡笔记本和现在手机一样都是几秒真男人

顺便,versioned object 的 rpc 是可选项,一般情况 select 操作是不启用 rpc 也就是不走 conductor 的

并不是有了 conductor,就要所有数据库操作都走 conductor 的,要酌情考虑

不要纠结微服务的名词, 这里提供一个具体项目的实现给你参考,这个项目就做了类似你说的事

openstack 的 nova, nova 之前也是服务自写数据库,后来拆分出了一个叫 conductor 的服务,后续版本各个服务都通过 conductor 来处理数据。

虽然我没参加过大型的项目开发,但是 openstack 就反馈出了大型项目开发会遇到的问题以及产生的解决办法
这个 conductor 解决的问题就是

大型项目中会产生很多版本迭代,对应的数据表结构会有各种变化
在微服务时代产生的更大的问题是, 大家不能一起升级！！还要一起跑！

举两个例子：
例 1：
比如说服务 A 和服务 B 都要写同一个表, 服务 A 有需求在表上变更的字段
最好的解决办法当然是服务 A、服务 B 同步表结构,但是因为各种问题 B 目前不能更新,这下咋办？

例 2：
有 1000 台服务器在跑服务 A,如果服务 A 升级变更表结构,怎么做到无缝升级？


为了解决问题, openstack 弄了一个叫 versioned objects 的玩意来解决上面的问题
通常的 orm 都是 model 映射到数据库的表,对 model 对象操作直接反馈到表上
而 versioned object 就是 model 上再加了一层（作用并不是简单的类似 java 的那个叫 dao 层的东西）
代码不在操作 model 层转而操作 versioned object 对象

versioned object 对象的操作落地操作就是将 versioned object 对象序列化后,rpc 到数据落地服务,也就是上面说的 conductor, conductor 还原 versioned object 对象再进行 model 的对应操作

versioned object 的主要属性就是 model 字段和对应值,以及 versioned object 的版本号, conductor 会根据 versioned object 版本的不同做对应兼容操作以便正确映射到 model 上, 对不兼容的版本报告错误


这样的结构就解决了上面的问题,兼容了不同版本的服务,也让升级变得平滑


微服务很多做法都是解决大型项目版本迭代而产生的,不一定是为了解决性能问题,从性能上找原因方向就错了

@julyclyde

你没明白我意思

我怕云服务器网络可能又策略对 P2P 行为有特殊处理
所以即使 bt 也用 webseed 而不是直接用种子分发
Local Peer Discovery protocol 这种有出扫描行为的功能我可不敢启动

@julyclyde

我现在没有内网环境...所以先随便找了个电影的种子测试

Local Peer Discovery protocol 这玩意在云服务器启动不好吧...会不会被干掉？

我知道了
tarcker 全是失败的
我又禁止了 dht...

有没有只用 tarcker 的的种子呀...还是我必须得自建一个 tarcker 测试....orz
我内网 bt 不需要 dht 啊 orz

我看了下 troubleshooting 图对比了下
我没能从 tarcker 里获取倒 peers....

就是没有 tarcker reply alert, 没开 dht 有关？

配置文件是字符串.没必要在配置文件部分确保他表达的对象正确
比如说一个动态加载的 backend, 你只要在配置里确保这个 backend 的字符串符合你自己定义的规范就可以
而不需要确保这个 backend 确实存在

同样我的 path 是否正确配置文件层面我只要确定 path 的字符串的正确性符合我的规范就是

因为配置文件代码最先执行,当然会前置错误信息....否则报错得到具体 api 调用的时候了

需求这个正则是因为路径最后要和 url 资源路径对应
配置文件层我就可以通过正则避免相对路径导致可能的越界
这样业务层就不用再检查路径问题了,只要处理 io 错误而不用每次都要调用一次转绝对路径函数


正则这个 if 我确实不知道,因为不是很喜欢写正则,今天会了过两天就忘记了,脑壳痛

@ceyes

1.配置文件模块只支持字符串做正字校验
2.尽量在配置模块中避免用户输入相对路径(并尽量保证路径字符串正确)
这样应用可以直接拼写路径而不用做一次转换

通过非正则方式校验简单.但是要在配置文件模块以外做
用正则就是为了在配置文件模块部分校验字符串而不是让后面应用做

oslo config 的配置提供了多种 opt,如果需要可以自己创建文件夹类型 opt 以及对应校验
但是这样需要载入自己的 class,所以才直接用了 StringOpt 加正则来做

https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py


@no1xsyzy
1.配置文件里路径绝对路径安全避免问题,又不是命令行工具次次要你输一长串
2.IDE 里用 r 有警告提示看着烦
3.oslo config 不支持直接传入校验函数,需要集成重写,原因上面也说了

rsync 可以走 ssh 不需要开服务的

@zhijiansha
谢谢...就是这个,比我之前处理文件名的那个写法好

我发现我之前也用了环视处理文件名,但是现在已经看不懂了 2333

@jaynos
配置文件模块只支持正则校验, 用访问目录校验就得在具体业务代码里做了

就是希望在配置文件模块里通过正则做完校验,这样更通用一点

转 pg 解千愁

换 pg 或者商业数据库

直接支持并行查询 你要是做好了表分区那更是嗷嗷的快

折腾 mysql 干啥呢

OpenStack 用 eventlet

你说呢

@ljpCN

jellyfin 你最好弄个垃圾 ssd 做缓存.... 转码会生成大量的文件

写单元测试的过程就是优化和重构代码的过程

写接口测试做不到

@KunMinX

做技术做傻了非要从技术上找原因当然找不到,本来就不是技术原因啊