markgor

markgor

V2EX 第 353333 号会员,加入于 2018-09-30 16:07:41 +08:00
今日活跃度排名 2009
根据 markgor 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
markgor 最近回复了
3 小时 0 分钟前
回复了 sengxian 创建的主题 程序员 求指路淘宝爬虫姿势
@jeeyong 你是在说某程吗,之前研究过携某的反爬,发现他们会通过浏览器特性来判断爬虫,
一但判定为爬虫,会直接返回相对高的价格,甚至后来直接不管是不是爬虫,列表价直接返回浮动价,只有预定价才会返回真实价,前端就弹出恭喜你,价格降低 xxx 之类的。
3 小时 12 分钟前
回复了 ysy950803 创建的主题 PHP PHP 服务挂了之后是不是就能查看. PHP 文件源码了?
@void1900
常规场景下他说的没错,
apache 太久没碰不确认,但依稀记得是通过 AddType 添加 PHP 的 mime 进去的
nginx 的话就是看配置.php 后缀然后转发 php-fpm

当然也有场景是 php 直接监听端口,nginx 按目录请求转发到端口,这种就和 mime 没关系。


回到 LZ 的问题,
Nginx 通过 phpfpm 转发的话 fpm 挂了,那么会产生 5XX 错误,不会反回源码;
一般反回源码的情况是 Nginx/Httpd 没配置好的时候(即没把解析 PHP 配置好),就会出现反回源码。
8 小时 37 分钟前
回复了 tellmeworld 创建的主题 程序员 什么样的水平可以做技术负责人/合伙人?
站群、咨询类的 PHP 居多,因为真快也不用考虑效率。
业务系统类的,PHP 占有率不算高,因为这一块真要用 PHP 去堆砌,暂时发现性能跟得上的只有 swoole 和 workman,
但实话说 workman 或 swoole 的开发思想上和平常的真不同,特别是 swoole 。
使用者的心态:
1 、你开源了就必须对项目和使用者负责;
2 、我现在使用了你的项目,出了问题,我需要的是第一时间解决,而不是参考一大堆资料才找到答案。

开源者的心态:
1 、我只是把我的思路开放供参考;
2 、线上服务使用了出现问题可以提 issue,回复效率取决于我的时间。

能理解使用者的心态,但不支持使用者的这种行为;
首先他需要弄明白什么叫 “商业支持”,大家的时间都很宝贵,
并且漫无目的的喷码不是解决问题的方法。
对于这种人,没必要回复,实在气不过,直接把记录截图放到项目首页作为申明。
好奇问问,JS 属于吗?
在服务端,有 nodeJs
在 web 端,有 vue
在 app 端,有 uniapp (本质也是 vue
在 pc 客户端,有 electron
好像真的什么场景都有 JS 的身影
1 天前
回复了 markgor 创建的主题 MySQL 请教 MYSQL 多表联查数据优化方式
@2i2Re2PLMaDnghL 感謝提點,後續我把那兩個思路也進行測試下;可能換 Oracle 會得到更好的效果,但投入也是巨大的。
1 天前
回复了 markgor 创建的主题 MySQL 请教 MYSQL 多表联查数据优化方式
@2i2Re2PLMaDnghL
Oracel 之前某个业务使用过,但就目前个人对 Oracle 各项优化方式和使用上并不熟悉,除非 Oracle 内部对查询器进行了优化,否则我觉得性能上估计相差不大,而且除去成本而言,用 Oracle 的话太多关联的程序需要改动,代价太大了;

之前也有业务上使用 Oracle,当时大概是因为 需要通过存储函数 触发 脚本运行 把数据提交去上级的 Oracle 中。
1 天前
回复了 markgor 创建的主题 MySQL 请教 MYSQL 多表联查数据优化方式
@2i2Re2PLMaDnghL

》且抛开这个
SELECT id FROM tbl_price price WHERE price.bookDate BETWEEN '2021-10-10' AND '2021-10-17'
170W 左右的數據,耗時 1.3 秒;

SELECT * FROM tbl_price price WHERE price.bookDate BETWEEN '2021-10-10' AND '2021-10-17'
170W 左右的數據,耗時 23 秒;

第 2 點測試過,效果基本沒變化;
第一點由於要加欄位,所以只能後續在測試環境中測試下
1 天前
回复了 markgor 创建的主题 MySQL 请教 MYSQL 多表联查数据优化方式
@wowbaby 业务形式不一样,我们的是酒店价格,所以价格是按日为单位,每天的都不一样,
酒店--product
房间--spu
销售计划--sku

常规商城的价格这个放去 sku 表中,
但酒店由于每天房型价格都不一样,所以还会多一个价格表,记录销售计划和销售日期 的售价;
比方说:
汉庭酒店
|--标准房
|----当天可售
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|----提前 3 天预定
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|----不可取消
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|--豪华房
|----当天可售
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......
|----连住优惠
|------......
|------2021/09/01
|------2021/09/02
|------2021/09/03
|------......


实际业务情况是
可能哪天,整个房型都需要停售,这时候 spu 上的 isActive 就设置为 0 ;
可能哪天,某个房型的销售计划停售,这时候这个 sku 的 isActive 就设置为 0 ;
可能哪一天的房停售,这个时候 price 的 isActive 就会设置为 0 ;


一般情况下,当携带酒店 ID 和入住日期去查询信息,返回时间基本是毫秒级别;
仅仅是当需要显示列表形式的时候(只有入住日期没有酒店 ID ),查询时间十多秒。
1 天前
回复了 markgor 创建的主题 MySQL 请教 MYSQL 多表联查数据优化方式
@disk explain 看过了,属于正常,现在困惑的地方在于优化...
因为从 product->spu->sku->price 条件关联后数据几何倍增,就如您所说的 14 秒是正常.但总觉得有地方可以继续优化但被忽略了.


@cppc 现在查询都是在从库进行的,我之前也是想把 productID 做去 price 表中,但是因为还有 spu 和 sku 可售状态筛选的问题
关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2164 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 11ms · UTC 11:03 · PVG 19:03 · LAX 04:03 · JFK 07:03
♥ Do have faith in what you're doing.