有些小众的歌曲国内平台上有人上传，但 Youtube Music 上没有，但如果不是喜欢小众音乐的话，问题不大。

Youtube Music 上没广告，而且印制也比国内音乐平台的免费音质要好一些，只不过没播放一段时间就会自动暂停，买会员基本也都是解决这个问题，不过我个人能接受，所以不买会员也挺好的。

https://developer.mozilla.org/zh-CN/docs/Web/HTTP
https://developer.mozilla.org/zh-CN/docs/Web/HTML
https://developer.mozilla.org/zh-CN/docs/Web/JavaScript
https://developer.mozilla.org/zh-CN/docs/Web/CSS/Reference

把这些全看一遍，对各种特性有一个印象，确保下次有需要的时候能想起来有个对应的特性可以满足需求。大概两周时间就足够了。

然后去看框架的官方文档，Vue 、React，官方文档的所有条目全看一遍，了解核心思想。

如果计算机基础不足就补一补数据结构、算法、操作系统、计算机网络。

然后简历写好一些，能进入面试的话问题就不大了，顶多再针对性地练练算法题。

项目经理和产品经理都是各自有专业知识和技能的，而且招聘更看重经验，得有拿得出手的成绩，否则就只能从助理开始干。

如果没有引起性能问题就不用管，这种都是机器人自动扫描漏洞的，有漏洞就会自动攻击。

如果已经引发一些问题了，你用云计算的话可以加个 WAF 。想要自己折腾的话也可以配置一个防火墙规则，当单个 IP 404 的请求超过某阈值就拒绝访问。

WSL2 是跑在虚拟机里的，虚拟机和 Win10 是相当于 2 台网络设备，所以你在 WSL2 里启动了一个服务，不能监听 localhost，而是应该监听 2 台设备同在的网络段，最简单直接的是监听 0.0.0.0:8000 。

然后找到 WSL2 目前在用的 IP 地址，比如 10.2.3.1，然后在 Win10 上访问 10.2.3.1:8000 就可以了，就像是你在自己电脑上访问一台测试服务器上的服务一样。

原生 JS 现在确实很强大了，手撸页面已经不像以前那么难了，很多以前主要由框架和库提供的功能，现在 JS 也有类似的原生 API 可以直接用了。

不过框架也是在发展的，一些原生 JS 具备的功能会逐渐被从框架中移除，而框架也会增加其他特性来增强原生特性的高效运用。比如之前各个框架都有自己的组件机制，后来 WebComponent 出来之后各个框架都开始对 WebComponent 进行支持，从完全自己实现组件机制到底层复用 WebComponent，然后表层再根据框架架构思想封装成更易用的特性。

原生特性是分散的，而框架往往是提供了一种现成的解决方案，让大部分需求场景可以直接套用，让开发者把精力更多放在业务上。

情商说白了就是一种能够预测别人反应的能力。

1. 说话或做事之前先预测一下别人怎么反应。
2. 说话和做事。
3. 观察或询问别人的反应。
4. 修正预测。

日常跑这个循环，就可以提升情商。

与此同时可以看小说、综艺来观摩别人的说话和做事的方法，以及随后产生的效果。

16 款升级后不卡，但经常 Crash 。

后来有了一波更新，目前暂没遇到 Crash，继续观察中。

我接触到的高可用设施确实通常建议至少 3 节点，但是大多 2 节点也可以工作，直至到剩下 1 个节点。

没有找到相应的理论参考，说一下个人猜想：
3 节点中如果 down 了 1 个节点，管理员需要想办法去恢复成 3 节点，此时可以修复 down 的节点也可以加新的空节点，不管是哪一种都涉及到同步数据的过程，此时剩下的 2 个节点中可以 1 个主要承载应用负载，另一个主要承载同步负载，使得同步过程不影响业务性能。如果是 2 节点方案的话，剩下的 1 个节点既要承担应用负载，又要承担同步负载，会使得应用性能容量减半。
如果是 4 节点的话，除非有其他设计加成，否则和 3 节点的效果差不多，只不过连续 down 2 个节点问题也不大。

@monetto 任何疑问都可以问 JetBrains 的客服，可以给他们发邮件也可以去 Twitter 上艾特他们。

我问过他们的客服：
1. 个人版可以用于开发商业项目，但仅限于自己使用。
2. 个人设备安装数量无限制，但是不能同时在多个设备上使用。我的设备超多，且一台 PC 可能都有三系统环境，都装了 IDEA 登录了账号，没出现过被封或不能用的情况。

@mitu9527 在主题内容中，你其实太纠结于“无状态”本身的含义了，但 REST 的作者可不是这么想的，你看论文的前几个章节，他只是在以往的 API 设计方法中遇到了一些痛点，然后希望借助“无状态”的思路来解决这些痛点而已，实现纯粹的“无状态”本身并不是 REST 所讨论的核心问题。
就像我们现在在程序上所说的“异步”，实际上是为“同步”需求服务的，我希望多个业务逻辑能同步执行，所以需要技术栈具备异步处理的能力，即在一个业务正在处理的过程中可以同时响应另一个业务（有什么活就做什么活，不等着）。在生活中，“我一边打电话一边敲代码”这种在语言表达上不能被称为“异步”（虽然职业病会首先想到“异步”），而是我在同步做两件事情（我有异步做事的能力，可以随时在想下一行代码和下一句回答之间切换）。

“In computing, a stateless protocol is a communications protocol in which no session information is retained by the receiver, usually a server.”——Wikipedia: Stateless protocol

首先，“无状态”是个简称，实际指的是“Server 无状态”，即在抽象意义上，Server 在处理请求的时候不依赖 Server 当前的状态。
举个依赖 Server 当前状态的例子就是传统的 Session 模式：用户的登录会话信息保存在 Server 上，Client 上仅保存 Session ID，Client 发送携带 Session ID 的请求到 Server，Server 读取本地的 Session 内容来确定用户当前的状态，再处理请求。
而无状态就是 Server 在接收到请求之后不需要读取自己在用户之前的请求所留下来的 Session 数据，仅凭借 Client 请求中携带的信息就可以完成用户状态的判断。

拿生活举例说明，比如一家理发店：
有状态模式每位理发师会记住自己服务过的每位顾客的喜好，每来一位顾客，都要问其以前是哪位理发师为其服务的，然后看那位理发师是否能继续为这位顾客理发，如果那位理发师抽不开身，就可以把顾客的喜好情况讲给另一位空闲的理发师，让这位理发师来为顾客理发；
无状态模式就是理发师不需要记住顾客的喜好，每位顾客来了就可以分配一位空闲的理发师，然后需要顾客把需求交代清楚，理发师按照需求进行此次理发服务。

无状态好处有很多，主要的几点：
1. Client 的请求对 Server 一视同仁，理论上此服务集群的任何一个 Server 随时都有能力正确处理 Client 的请求。
2. Server 对 Client 的请求一视同仁，处理每个请求不需要参考同一用户前几次发了什么次请求，仅考虑当前请求包含了哪些信息。
3. 服务集群不需要考虑是否要同步各个 Server 的状态，因为 Server 无状态可同步。
4. 负载均衡不需要考虑引导请求到集群中特定的 Server，可以放心地按照实际负载分布来分发请求。
进一步产生的好处为：
1. 服务器程序设计简单，每个请求的处理过程是独立的。不会遇到请求与请求之间的逻辑关系而导致程序复杂。由此接口设计模式可以很简单、清晰。
2. 服务集群性能是和机器数量等比相关的，性能不够加机器就行，不会因为加机器而产生额外的开销。

当然，无状态设计也会有一些代价，比如每个请求都需要携带较多的状态数据，而 Server 可能也需要每次收到请求都执行一遍对请求中状态数据的解析。

系统架构上的概念都是抽象意义上的，比如无状态概念里的“Server”指的不是我们一般说的物理意义上的服务器计算机，而是在系统架构上处理业务请求的那部分程序，这其中甚至都不包括底层数据库，但可能包括或不包括实际实施中使用的一些中间件。
所以在尝试理解系统架构概念的时候，要先理解概念里的每个名词究竟代表的是什么，再看实际实施过程中，这个名词指的是整个系统的哪些部分。

国行限制多，如果了解了国行各种限制之后仍然符合需求可以买国行。
如果对限制忍不了就买国际版（日版、美版、欧版等等，不锁区，商店的分区跟着账号里的资料走，可以随时改），各方比价，找划算靠谱的。

写程序难题 Top2：起名和维护缓存。

把缓存和数据库的操作封装在一起，对业务功能仅提供统一的接口，接口被调用后内部管理缓存和数据库的操作。

基本思路就是有读的话直接去 Redis 里读，有写的话先删缓存，再写数据库。

可以在写入的时候使用事务，确保写入的时候数据库里的值没有被其他应用实例修改，如果遇到了就尝试二段提交。

考虑到缓存刚刚被删除就有可能有读请求进来，为了确保一致性，可以在删缓存之前在数据库记录中加一个锁（类似排他锁），等更新完再解锁。

数据库层级的事务在引入微服务思想和各种中间件、数据库之后，会有较大的局限性，此时就要更多考虑分布式事务方案。

亡羊补牢，为时不晚。

幽门螺旋杆菌会加重胃病，现在治疗手段也很成熟了。

用记账 APP 把收入和支出进行记录，还可以做一些攒钱计划或者不同项目的支出预算。

钱也不用非要存到一起，除非需要理财。

大一些的支出稍微商量一下就行了，比如买电子设备、随礼、名贵衣服啥的。可以时常匀一匀余额。

关键还是两个人要有默契，了解对方的想法，并能互相迁就。

看未来有没有国产化要求，有的话这个时机可以调研一下国产的发行版，免得不久之后又要换一遍。

RedHat 停止支持 CentOS 的目的很明显，让用户都去购买他们的 RHEL，有支持服务的，所以领导觉得能接受的话可以找 RedHat 的销售谈一下。

Ubuntu Server 也是个老牌 Linux 发行版了，使用习惯可能与 RedHat 系发行版有一丢丢区别，但稳定性没问题，注意官方公告就好。
Debian 也超级稳定，但这个稳定性是来源于升级慢，基本只有安全更新是比较及时的，软件特性上只有大版本系统更新才会引入。
SUSE 、openSUSE 有人说也不错，可以了解一下。