这个公司有没有长期维护一个产品的计划,同时公司的经济收入能不能支撑他养一波开发产品新需求的人员。
如果只能靠不停接新的订单进行开发,同时老的产品没有新需求的开发规划,这不过是销售导向的外包公司,赚够一笔跑路费就走吧。
透明代理在有意分析的情况下可以检测出来使用了代理。实际情况上,是否使用代理并不是重点。容易被清洗的请求通常是 ip 黑名单,就是这个代理 ip 发出来的请求数量太多,加上服务端有意收集 ip 黑名单进行的清洗。
如果只要代理池里面的 ip 没有太高的流量出去,问题都不大。
切分就是 100w 的导出数据, 不要一次取出来,可以分成 100 次,每次 1w 的数据量进行解析之后写入文件的处理。
你从淘宝看导出的前端业务像是两步,实际上, UI 显示同步数据进度的时候,它后台对应的是一套任务队列,拆成很多步的导出处理,最后导出的数据都保存到文件之后才会显示真实的下载地址。
代理买最省事,免费代理可用性太低。检测可用性的维护成本也很高。
基于要解析 HTML 内容这个事情,不考虑用 nodejs 做解析么,异步加上 js 的支持,要省很多事。这样用户就可以只写 js ,很容易隔离。
百万数据转移,一次取出来太耗内存,代码也处理不了那么快,切分一下,写个导出的任务队列,把任务切成多次写入,开个进程专门跑导出。
尽量去公司的核心业务部门做技术。资源和话语权大的情况下做起事情效率高很多。
基于这个前提下面,能去越大的公司越好。
实在没实力进核心部门,想提高技术就去技术话语权大的公司。
高并发大流量高可用的公司其实不少,想做这类的产品就去那些有自己独立产品的公司就好了。只要稍微大一点的公司,有个几十万用户规模都会开始处理流量问题上一些高可用方案了。
外包项目不是没有这种类型的,只是外包的话通常没有话语权,拿到需求就干活,很多需求的提出和决策没办法了解前因后果,如果不是长期外包的项目,也很难跟踪一个产品的演变,对经验积累的提升有限。
需要一个任务队列,抓取线程从任务队列里面取任务抓取。
又或者把抓取功能封装成一个独立的任务,主线程通过直接调用的形式直接分配任务。
类似的定位+宠物小精灵捕抓的玩法,在 2013 年就有尝试做的了,我在 b 站看到过宣传视频,就是 ingress 的玩法, Google 地图+AR 增强。不过那个游戏并没有活下来,悄无声息得死了。
要处理中文词组建索引,基本上都是 sphinx for Chinese 这个项目做的。
sphinx 查到 ID ,再根据 ID 去数据库取数据这个思路并没有大问题,上个内存缓存,按 ID 作为 key 存一下,可以节省一些重复查询的性能。
那你们的业务支持一次 sphinx 查询就取出这个分页的所有数据 ID 了吗?
再深入一点的调优,词库多大,查询的词在不在词库里面,你这次 40 秒的查询,对应的是 sphinx 的什么查询,这个查询出结果耗时多久。
最终根据 ID 去数据库取数据又耗时多久。
外包的团队能不能把执行时间和性能消耗量化出来。如果他们就知道搭个环境直接跑,不知道如何检测分析性能消耗在哪个阶段,那根本没法调优了。
公开信息采集不违法
如果实时采集的延时不大,可以考虑实时,实在量级大了才考虑用缓存
国外服务器不需要备案,目前微信只要求域名且只使用 80 端口,变相要求在国内的服务器备案,如果国外服务器,可以直接使用域名+80 端口访问得到,就不需要备案。
用 sphinx 建好词库了吗,词库决定了查询的精准度和性能。
单次查询四十多秒应该是不会用 sphinx 的锅,本质上 sphinx 还是聚合数据源的多条 SQL 语句,做缓存以供加速。如果单次查询需要那么久,说明对应的 SQL 语句执行更久,还可能没建好索引。
索引词库要维护一份精准的词库,这个最重要。
内存开了多大,如果内存里面缓存的索引数据足够完整,性能也可以提升很大。
其次数据源存储位置放 SSD 里面也有性能提升。
涉及优化会有调优的要求。
PHP 就是 C 语言系的技术栈。
基础上自己用的语言框架性能瓶颈可能在哪里。
引用的环境中各个软件的性能和使用场景。
思路上多看看别人分享的架构,看看别人会用什么高性能的软件增加系统的性能、容灾性。
比如查询优化,穷尽心思在 SQL 语句上面调优可能没有加个 Redis 上多级缓存来得简单粗暴。
复杂查询上面也许只要一个 sphinx 、 elasticsearch 就可以解决复杂多变的查询需求。
至于业务上使用工具还是自己堆代码,就看经验了。
万不得已别删数据呀,万一需求改了,要看上一年的房间状态,或者看上月同期的房间状态,没有数据不就疯了。
让每个房间每天的记录都独立作为一条数据,方便后期计算。
你这种用位标识合并多个记录到一条数据的做法,更像是把数据序列化在文本中。从零开始做一些小功能的时间会用这种方式。
既然有数据库,有些计算处理是可以交给数据库做的,没必要什么都在程序做。
楼主想复杂了,数据集一条就三个字段必须,房间 ID ,房间状态,房间状态对应的日期。这个表就存基础数据,每一天的房间状态。
可以在表里面做一下冗余字段,比如楼层,房型,当天销售价格之类的方便后期做报表计算。
至于你要的九十天内的房间状态报表,完全可以根据表里面的基础数据做计算,需要的时候再按房间 ID 和日期取指定房间最近九十天的数据出来,用程序处理一下汇总,比如 select * from room_status where room_id= 1 and order_time < xxxx and order_time > yyyyy 。把基础数据取出来自己算。
这样每天房间的状态都是一条独立的历史记录,删不删都可以,增加和汇总报表的成本也不会太高。
每个房间每天一条新纪录就没有这个冲突的问题了。
查询当前空房和房间状态历史记录都方便。
我提的建议不是 id*num1+num2
而是你目前做的预先生成随机序列插入 Redis 或者 MySQL 中。
这个不是算法的锅,查查 PHP 配置环境的内存限制和执行时间限制, Redis 的连接时间也可以查查。几百万条记录的数据分析我偷懒的时候也是一个脚本跑完,跑个三五分钟是常事。这个数量级的处理和内存占用不应该崩。
小优化的话, Redis 可能不需要全部随机数塞到队列了再执行,可以间隔三五千个就执行一次提交。
如果还要更快的生成速度,那就把生成切分任务拆到多进程去,可以开一个常驻内存的进程做任务调度,专门调度多进程去生成随机队列了。
偷懒就用 swoole ,它有 task 的样例。
自己写简版的也行,无非就是 crontab 开个定时任务,定时唤醒调度脚本,用 pcntl 模块检查进程里面跑的任务数够不够,不够就开新的。
Redis 开个任务处理队列,任务进程的脚本定时去取任务出来执行生成指定范围的随机数并插入 Redis 的商品对应的队列中。
上淘宝做定制爬虫,有无数个人站长需要有人帮他们采集数据堆他们的垃圾站,同时也可以兼他们的运维。个人站长这个领域已经没落,还不知道能吃几年饭。
如果有前端的技能栈,可以做很多基于应用内嵌浏览器的定制活动,比如微信公众号的活动或者小游戏,这块最近几年很多公司涌进微信做客户关系管理,还可以吃几年。
开一个个人兴趣的坑,补一下这个领域信息化的空缺,花几年养起来,一样可以坐收广告费维持好多年,比如 V2EX 。
做在线教学,开公开课教程,能力不够就做新手入门,能力够强就做中级难度的教学,职业教育这个也是一个不错的自由职业,延伸的发展就是挑个地区接下一部分公司的技术顾问。
做验证码图像识别算法开发,配合 js 这个领域在 web 依然有很多年的对抗可以做,针对很多大站做验证码识别可以卖服务给很多刷量的公司。
图像处理这块因为门槛高,所以需求的开价一直都很高, python+opencv 去深挖这块的需求,不容易被技术革新踢出局,经验和年限的加成非常高。
外包最容易打击新手的编程积极性。我认识的人里面,退出开发岗这个行列的,都是去了外包公司被打击的,重复的工作内容,超量的工作任务,基本没有留时间给在职人员学习新东西。自学能力稍微差一点的,干三年就到顶,发现自己总在做重复的代码开发,跳出来发现自己毫无竞争力,一年经验干了三年,除了外包公司哪儿也去不了,就转行了。
至于所谓的外包公司可以快速提高技术,那是基于驻场外包并且驻场公司管理极其规范,项目进度安排合理,给员工留够在职培训的时间,个人自学能力又很强的。 有这个条件的人,去一家好好做产品的公司一样成长很快。
别人去大厂是做螺丝钉,而去外包公司就算是做螺丝钉的应急备用品。
至于去普通小公司,那就是救火员型万金油,产品成长起来有机会变全栈工程师,产品如果一年就倒,那比在外包好不了多少。
刚入行第一年去那个公司都可以学到很多东西,最关键的区别在于第二年之后的选择权,在外包公司的视野就要差那么一点点。外包没有那么坏,只是选择权少了一些,非要一条外包路线走到黑,也不会太差,只是这条路的淘汰率太高,整个外包公司的文化都是尽可能让员工可替换,成长空间有限。
不要说懂,单单知道一点攻击手段和安全策略,开发出来的代码质量都要比不懂的健壮性高一截,可以避免很多不必要的 debug 。
要是再有安全的基础了解攻击原理,那就说明可以理解不少工具框架在边界条件和缓冲区的实现方式,调优起来简直是插上翅膀在飞。
后端语言和架构的生命周期更长一些。十年前后端处理数据要用的语言、框架和开发库的经验,放到今天依然可以平滑迁移。十年后 C++ 、 Java 应该还有一席之地。
前端做效果的生命周期就短一些,可谓是一朝天子一朝臣,经验上面的积累可以保留,但是语言倒是换了好几波。
桌面端的 C++、 delphi 、 C# 。
Web 端还略稳定,除了 flash 被边缘化, html 、 CSS 、 JS 地位依然稳固,但是各个浏览器对于 html 标准的支持程度不一,处理兼容性的活略坑, JS 上提升生产力的框架一波又一波得更新,有一点学习门槛,但开发效率真的提高了不少。
移动端变化最大,这个领域发展迅猛,变革周期很短,一个大厂的衰落就拖垮一个开发生态圈。十年后移动端是不是还会用 java 和 swift 来开发?
后面还有 VR/AR 这个大杀器,这个市场一旦成熟,必然会掀翻之前的前端生态圈所积累下来的开发库,所有做效果和交互的开发生态圈和工具都会革新。
全取出来自己计算关系没有完全发挥数据库的性能,循环主体是求四个集合的交集。
属于某医生的药品
不属于某医生的药品
属于某疾病的药品
不属于某疾病的药品
这四个集合有没有办法通过单表查询从数据库取出来?
如果按医生为主体循环,那么是否属于某疾病的药品这两个集合可以缓存在内存中。减少很多数据库查询请求和循环处理。
预处理取出这些药品的分类集合并且按药品 ID 排序之后。
主循环的业务就可以调整成求四个集合直接的交集,这个就可以通过归并排序的思路求交集,当然 Java 内置方法也有求交际的库可以用,只要预处理好,性能应该还可以优化一下。
第一种的 sql 应该是 update saleorder set orderuser={uid} where orderuser=0;
这个操作是之前 v2 上一个做电商的老鸟公布的,预先插入库存的数据,预留订单用户的字段,通过 update 这个原子操作锁表保证订单不会超售,同时这个只要建好 orderuser 这个索引,单凭数据库就可以扛很高的并发操作。
至于购买请求远远高出库存的瞬发请求,还是预分配,不过得用 Redis 来扛更高的并发业务和限流。