1. 首先你得定位攻击的类型，是 SYN Flood ，HTTP Flood ，还是慢速攻击。从你的描述上来看，CPU 异常升高的话，应该是 SYN Flood 。
2. 确定抵御的方案，知道攻击类型的话，针对攻击的特征，需要确定防御的策略。因为 SYN 攻击是针对 SYN 的，所以先：sysctl -a | grep syn 看看本机的设置
其中 tcp_max_syn_backlog 是 SYN 队列的长度，tcp_syncookies 是一个开关，是否打开 SYN Cookie 功能，该功能可以防止部分 SYN 攻击。tcp_synack_retries 和 tcp_syn_retries 定义 SYN 的重试次数。那么先 加大 SYN 队列长度，然后减少重试次数（减少重试次数有副作用，就是在网络不稳定的地区访问，正常访问失败几率会升高），另外就是要加上访问频率限制，比如超过每秒一次的 IP 就 ban 掉 30 秒。

还有一种方式就是挂 cloudflare ，CF 的机器肯定都是有做好上面我描述的抗 DOS 的设置了，另外一个好处是，有更多的 IP 来参与分流，可以提高你的冗余度。

另，阿里云的云监控里可以设置对主机的状态监控，CPU ，内存，磁盘，可以设置阈值，超过了就给你发短信

明年请早

大部分的应用瓶颈不是在开发应用的语言，而是 SQL......

人家图的就是你的本金

你可能需要换一辆车。电车就不存在所有你说的这些问题。并且很多电车是带终身流量的

买台二手的 86 吧，手挡，86 是能培养车手的好车子（拓海父言）

就用铁锅，你得学会玩锅，新锅到手要会开锅，用着得学会养锅，学会了就不回纠结了。
首先得会开锅，买新锅的时候顺便买一块带皮五花肉，先把新锅子用清水洗洁精完全洗干净，纸巾擦干，大火烧到锅变色，转着圈烧，变色不是说烧红，是变成烤蓝的颜色，大约就是 10-20 分钟，然后等锅变凉，再开小火加热，等温度上来后，用五花肉切下来的猪皮，脂肪面朝下，用筷子或者夹子沿着锅边转圈涂，用猪皮擦完一遍后，等锅自然冷却，然后用温水冲洗一遍，再用纸巾擦干，之后开小火加热，换一块新的猪皮来转圈擦，擦均匀后等锅冷了，就开锅完毕，可以正常使用了。
今后每周执行一次：开小火加热，等温度上来后，用五花肉切下来的猪皮，脂肪面朝下，用筷子或者夹子沿着锅边转圈涂，用猪皮擦完一遍后，等锅自然冷却。这个步骤。这个锅就会一直很好用了。

另，要想不沾，热锅凉油

尽你最大的努力撸网贷，能撸多少撸多少，然后去走线

真机的 CPU 和模拟器没法比啊，之前写了个多线程下载的功能，在模拟器上跑得飞快，上了真机就卡到蛋，仔细想想，iPhoneX 是啥 CPU ，多大内存，调试用的 Mac 是啥 CPU ，多大内存。

这点预算不够，也就够你跑跑 yolo ，大模型是跑不起来的

最近的话，可以去缅甸，云南有代理可以帮你办，你不用出境

你入了不知道干啥，再便宜都是亏，我入的 199/yr 的，足够小型项目的启动了，马上新项目就启动可以用上了，另外一个 99/yr 的已经有项目跑在上面了。
你自己不干正事，才吃灰的，怪别人优惠时间长算什么事

记得有猛人，把这个鼓包当水泡给挑了，然后不出意外的烧起来了，你试试找个手套式全隔离实验工作台，把里面充入纯氮气，然后在无氧环境下把鼓包给挑了，排除气体后，把挑破的部分用补胎的胶贴粘起来保证气密，说不定还能继续用一阵

没怎么耗电，且我也没用什么小火箭，随用随开，用完就关。
方法是，家里的 OpenWRT 上除了翻墙小火箭外，再多部署一个 VPN Server ，最早是用花生壳的动态域名，但是没花钱的切换不是很及时，有时候急用的时候死活连不上，后面因为有个阿里云的小实例，在上面部署了一个 FRP ，就换了 FRP 来转发。这时候在手机上配置好 VPN ，就能在任何地方用家里的网络翻墙了，速度的话启动慢一点，但是看 youtube 视频没啥问题，还有个好处是能更方便的访问家里 NAS 上的内容，而且不需要把 NAS 暴露到公网上

首先你需要先从建模开始入手，合理的模型才能高效的驱动业务，然后模型的持久化，数据库只是一种选择，文件，redis ，远程 API 也可以是持久化的一部分，把适合数据库的部分拿出来，再来说数据库表设计，数据库表和模型实体之间并不是严格的一比一的关系，虽然很多时候是一比一。一般来说基本原则还是遵循 3NF 范式，但是在某些地方，根据模型和业务的实际情况，需要做一个些反范式的设计，比如某些在 3NF 范式下 JOIN 深度超过 2 层的地方，用冗余字段降低到 2NF 范式，某些模型实体比较大的，根据访问频次，可能会切分成几个表，比如用户，用户的登陆信息和用户的属性就需要切分成两个表来存储，如果有一些统计字段，也会单独用一个表来存，因为登陆信息一旦插入，几乎很少修改，而属性则因为运营关系经常有需求会修改加字段，这个时候分开表就不容易被卡住。有用户的统计字段的话，因为经常性的更新统计信息，这个表比较热，所以更需要和其他几个表分开，这样保证了 1 ，模型的完整性 2 ，可扩展性 3 ，效率。做好设计后在纸上预跑一遍，不要依赖就急吼吼的拿起工具就建表，预跑一遍，把 SQL 写出来，然后才好规划索引，另外就是根据实际的业务来计算一下预计的容量，也是你系统的设计容量，比如有的表撑死了也就几百条一千吧条数据，那你除了主键外都没有必要建多余的索引。有的表预计记录条数超多，那么提前考虑好是否需要分表，分库。

在真实世界里完美的设计是不存在的，因为其实完美的需求是不存在的，而好的设计和坏的设计的区别就在于如何取舍上，这个问题貌似没有哪本书能给你完美的答案。认识一个家伙特别喜欢买书，各类大作堆了一墙，但是能看完的，本就不多，看完了的，貌似也没啥用，搞数据库设计还是稀烂，经常扯到蛋（还是客户端的数据库）