不要把 pg 和 mysql 放一起啊, pg 可以对标商业数据库,mysql 可不行

mysql 就是不能做复杂查询,数据量一大就玩完。

mysql 没有足够的统计数据根本不能做查询优化路径选择

不要迷信什么大厂也用 mysql 做复杂查询,人家应用层和数据库层都可以定向设计,可以玩出花来,我们可不行

普通用户老老实实用 PG 做这些

因为 mysql 干这事会死....

蹲下来干活半天, 就凭程序员这腰哪里受得了

我姐装修最后自己做了美缝, 我被抓去帮忙干了半天立刻得出这钱我挣不了

哈哈哈

我也有过你的阶段, 最后我突破这个阶段通过学习 openstack

几个建议,目前阶段

算法不是那么重要,但你必须有基本算法思想,能写二叉树,熟悉分治算法,几个排序算法都熟悉就可以了,起码你看到某个地方特意用了某个排序算法,能理解这里为什么用这个算法来排序
设计模式大概读一下就行了,设计模式是用来解决问题的,你没感受到问题光看很难理解的
多线程、异步要自己好好写一下,不要流于表面,一个简单的聊天服务器作业能让你基本熟悉
熟悉多线程异步以后,认真把协程过一遍.我推荐读 python 的 eventlet 源码,读透,所有协程都难不倒你了

上面几个达成以后,
你应该去读懂一个完整的“项目”, 项目做什么解决什么问题,如何实现,当你比较熟悉这个项目的时候,很多问题就自然解决了
然后你照着这个项目实现你自己的东西,在模仿过程中你会更深入了解这个项目的痛点以及解决问题的思路,这样你就提升非常大了

目前比较适合模仿的项目有 k8s 啊 openstack 啊什么的,不要去刻意去读框架,因为框架不重要,特别是 PHP 的 web 框架


因为我自己学的是 python,对 linux 和 qemu 和 openvswitch 比较熟悉,于是学习了 openstack,非常幸运的就突破了写代码的瓶颈阶段,后面对 openstack 的模仿越来越深,提升也相当快


记住,人类写程序的思路和人类应对现实问题的思路是一致的,比如说网络包其实是邮件信封邮筒之类的抽象
解决任何程序或者代码的问题思考方式和现实是关联的


你先要有问题,再解决问题才能提高

最后别光瞎看...写起来

对外 url 表现,只是壳,所以你不理解

包括外面的壳在内..服务端的代码和设计都是适合 restful 方式的才算 restful

比如你可以参考 openstack 的 neutron,这个项目的就是完完全全的 restful
但是 openstack 的 nova 就不是 restful

一个原因是 nova 比较早,当时没有按照 restful 的方式设计,还有一个问题是 nova 的 api 不是那么适合完全用 restful 表达


如果你的业务适合用 restful 表达..那么对外接口和代码设计上可以有很强的一致性
否则,不应该被规范束缚,就像不应该完完全全用范式来束缚数据库设计一样


其实之前论坛里有个人非常精准的形容了 restful——对 sql 的劣质模仿

顺便 PHPer 没用过 swoole 不是问题

没写过服务没做过异步编程没写过池才是大问题

思路都会比别人少一大部分

@ohao

PHP 起于 fastcgi 死于 fastcgi, 因为绑死 fastcgi 导致生态和开发人员专注方向窄

setuid 也不是正确做法...正确做法是配专用的 sudo, 更正确的做法不应该在 web 服务器中运行, 规范做法是 rpc 发送出去让干这个活的专有服务做

曾经飞在封口上的 openstack, 那么大项目都走下坡路

扯什么 django tornado 就算了

@murmur

这么说吧, 学 react 需要更少的 html 知识
只要知道 div 和有限的几个 style 就可以上手了

对于完全没有前端基础的人来说 react 入门更简单

@murmur

你这是写过 css 用过 jq 的后端

完全不写 css 、jq 的后端更喜欢 react

没学会走就开始跑就这结果了

正正经经的把异步编程写几次,什么 select,epoll 多线程都好好用过几次再来折腾协程吧

别堕落到低端 php 程序员的水准好么

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

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

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