1. 万能 array/string ，加上一系列 array 的内置函数，什么一维二维转换，排序，提取全部 key ，提取全部 value ，数组合并等一系列业务中对于数组的常用操作都可以用一个内置函数搞定。字符串等操作更方便。
2. 比较优秀的 ORM ，collection 等等。基本不见 sql 代码，只要不是超级复杂必须用原生 sql 的逻辑，只要定义个 model 全都解决了，甚至不定义 model 都行，内置的各种 ORM 方法可以很快的解决一些非常简单的 curd 逻辑。
3. json 处理友好，数组/对象很方便的转成 json ，也能很方便的解析 json 。也跟 php 的弱类型有关，如果是 Go 这种强类型语言还得定义个结构体。当然强类型语言也有好处，但是开发效率确实会慢一点。
4. 无内存泄漏/全部 builtin 类型都是线程安全的，完全不需要考虑什么加锁之类的。没有并发心智负担。
5. 比较现代化的包管理/还算丰富的社区包/扩展，基本 web 常见问题都有对应的包。
6. 比较好的向前兼容，例如你用 php5.4 开发的代码，直接换成 php7 有 99.99%的可能性没有任何问题。
7. lnmp 架构比较简单，运维心智负担低，四五台中配机器抗起几万的 qps 没啥太大压力，性能也还算凑合。

当然 php 也有很多缺点，这里就不讨论了。

看完了，简直跟我最近入职的一家小公司太想了

面试官问你的这些问题都是 pua ，不用想太多，换谁都搞不定的

制度和流程是烂的，最终产物一定是烂的，毫无疑问。

写的很好，深度好文，我感觉就跟 lz 一样送了好久的外卖一样。

之前有个朋友教育我，之所以能看到网上程序员吐槽 996 那是因为我们靠近互联网，一大堆线下的普通人干的比 996 还累挣得还少，只能说成年人没有容易的啊。

php 最大的优势还是在与 fpm 模式下 web 业务的快速开发，你既然有网络协议相关的需求，那就用 go 写，然后用 php 调用就可以了。没必要用一个语言去做它最不擅长的内容。

加密只能提高逆向成本，我有个招

首先接口需要登录，记录用户请求次数，人工分析出来哪些账号是爬虫，其实这点很容易分辨。

然后把高度疑似爬虫用户加到一个名单中，命中这个名单的请求，随机的在正确的数据中插入一些脏数据。

同时为了防止真正用户受到影响，也可以在前端加个提示就说网络错误让用户刷新一下，下次的请求不要写脏数据就行。

这样一段时间对方肯定不爬了。

我的习惯是 repo 这一层打印日志，上面零星会打印一些关键日志。

@yongliu #3 抱歉我也没找到方法，所以我放弃用 onedrive 了 我用的是 syncthing 方案。

dynv6 免费好用，也不用啥 ddns 客户端，直接写个 shell 检测一下 ip 然后 curl 就能更新 ip 超级好用

Remotely Save 这个插件确实很多人吐槽丢笔记之类的，我从个人使用体验上来说，感觉也很难用。建议直接用 onedrive 之类的直接同步就行，别相信官方的提示，用的好好的。

先别说 3 个月能不能拿满了，就算给你 3 个月也是只有 80%，剩下 20%是股票，分 2/1/1 年兑现
一个组差不多就能分到一个 4 个月，如果有一个 4 必然有一个 2

小菜鸡一枚，尝试回答一下，以下答案没查阅资料也没参考楼上大佬们的答案。

1. 这个问题我觉得可以分开讨论一下，首先如果真的只是学校的抢课场景，从经验来说，那就算有并发也不会有很高的并发，在不保证高可用的情况下（如果真是学校抢课，没必要真的做什么高可用吧？）单台 redis 足够支撑需求了，最简单的实现肯定是 setnx ，但是可以从这里延伸一下，例如锁的时长要设置多久，锁过期了怎么办，要不要重试等等八股文，也可以用 lua 脚本，但是缺点是什么巴拉巴拉（掺杂八股文）
但是如果不是简单的学校抢课场景，而是电商的抢购商品这种场景（说时候电商秒杀的八股文和方案大家估计背的比我熟了吧？）既要保证高可用也要数据一致性的情况下，我觉得可以这样设计：

a) 根据以往秒杀时期的数据前提下，前端直接抛弃一部分流量，例如只有 20%的请求才能真正的请求，80%的请求在前端直接抛弃。
b) 秒杀请求进入队列，这样可以把对 redis db 等资源的峰值削平避免服务出现毛刺。由于是秒杀场景，失败了用户也会重试，所以完全可以不在意消息是否会丢失，这种情况下 mq 的性能绝对是能承载主流量的
c) 在消费的时候，再按照商品纬度加锁，这里可以用 redis 集群模式，也可以用 zk 等等组件，调你熟悉的讲，例如你熟悉 redis 的 redlock 那就讲 redlock ，熟悉 zk 脑裂你就讲脑裂

2. reidis 内存满了怎么办？我认为有也得分类讨论（前提是 redis 满了已经导致服务不可用了，如果配置了内存淘汰策略那就不用在乎满不满了）
a) 首先确认这个 redis 里面的数据是不是全是“缓存型数据”，如果是，可以挑一些 topn 的 key 先删一批，先让服务正常可用，然后迅速扩容，如果能动态扩容最好，如果不行先用 rdb 复制一台更高规格的 redis ，然后切换过去。
b) 如果 redis 后面不是传统 MySQL 或者 qps 不高的情况下，直接重启是最好的办法，当然这种情况不太常见，如果 qps 过高可能会直接拖垮 DB 。
c) 这件事的关键是要做好事后复盘、做好防护，避免下次再出问题，一个是要增加 redis 内存监控告警，超过 80%要告警，其次要配置一下 redis 的缓存淘汰策略，（这里也可以卖弄一下 LRU 之类的八股文）。

3. 我认为并发问题就是资源竞争的边界问题，解决并发的问题就是让资源竞争的请求从并行变成串行(加锁)，让无序变有序，让混沌变秩序。这里可以卖弄一下读写锁，互斥锁，CAS ，原子操作之类的八股文。



其次，有一些关于面试的经验，想分享给 V 友们。

1. 面试跟谈恋爱是一样的，眼缘最重要，而不是闯关或者解密游戏，答对所有题，写出所有算法，不会决定你能否通过，能通过面试，一个是因为合适，一个是因为眼缘。而我认为后者的占比更大一些，所以建议可以适当处理一下个人形象，面试的时候别太颓废，别太随意。不管是面试还是生活中，看起来让人舒服的人，总能占更多的好处。

2. 面试的时候，问题不会，算法不会是很正常的一件事，计算机的知识没人能做到全都懂，你需要做的是把握面试节奏，让面试官去讨论你熟悉的东西，引导面试官的话题。例如楼主的题目，问你 redis 怎么实现分布式锁，如果你不熟悉 redlock 但是你熟悉 zk 那就说不好意思面试官，xxx 我不太熟，但是 zzz 我用的比较多，zzz 的原理是这样的 balabala 。要把节奏掌握在自己手中。

3. 面试官不一定能决定你是否通过，很多情况下还是 HR 话语权大一些

4. 面试前最好了解一下面试的公司和部门，他们有什么产品？主营什么业务，熟悉一下，对方问起来可以增加一些好感。

5. 面试必问，自我介绍、离职原因、语气薪资，这些问题一定要提前想好避免回答的时候大脑一片空白。

@Wcowin #12 那可以考虑买个香港的虚拟主机，靠谱一些的也不贵 一年 100 以内，服务器不是说不行，就是灵车漂移的 oneman 商家有点多，靠谱的平台又贵

推荐 netlify 吧 够用了

扫描后门的 ban 掉这个 ip 吧

升级 dsm7 Synology Photos 目前看起来是最优解了

转码是因为没洗白，其实半洗白就可以 网上随便找个 sn 半洗白一下就能转码了

是在不行看看 immich 能不能满足你的需求？

onddrive 的话你可以上 office365 的订阅啊，40 一年，1t 空间足够你存很多歌了，还有正版 office 可以用

@karben 字节