1.反爬虫措施：
1、封IP：网页的运维人员通过分析日志发现最近某一个IP访问量特别特别大，某一段时间内访问了无数次的网页，则运维人员判断此种访问行为并非正常人的行为，于是直接在服务器上封杀了此人IP。
2、封USERAGENT：很多的爬虫请求头就是默认的一些很明显的爬虫头python-requests/2.18.4，诸如此类，当运维人员发现携带有这类headers的数据包，直接拒绝访问，返回403错误
3、封COOKIES:服务器对每一个访问网页的人都set-cookie，给其一个cookies，当该cookies访问超过某一个阀值时就BAN掉该COOKIE，过一段时间再放出来，当然一般爬虫都是不带COOKIE进行访问的，可是网页上有一部分内容如新浪微博是需要用户登录才能查看更多内容。限制每个每天下载300张.
4、验证码验证：当某一用户访问次数过多后，就自动让请求跳转到一个验证码页面，只有在输入正确的验证码之后才能继续访问网站
5、javascript渲染：网页开发者将重要信息放在网页中但不写入html标签中，而浏览器会自动渲染<script>标签中的js代码将信息展现在浏览器当中，而爬虫是不具备执行js代码的能力，所以无法将js事件产生的信息读取出来
6、 ajax异步传输：访问网页的时候服务器将网页框架返回给客户端，在与客户端交互的过程中通过异步ajax技术传输数据包到客户端，呈现在网页上，爬虫直接抓取的话信息为空
原文链接：https://blog.csdn.net/qq_42739440/article/details/89947395
2.tcp和udp区别：
1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。
3、UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。
4.每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP对系统资源要求较多，UDP对系统资源要求较少。
3.
newCachedThreadPool：
- 底层：返回ThreadPoolExecutor实例，corePoolSize为0；maximumPoolSize为Integer.MAX_VALUE；keepAliveTime为60L；unit为TimeUnit.SECONDS；workQueue为SynchronousQueue(同步队列)
- 通俗：当有新任务到来，则插入到SynchronousQueue中，由于SynchronousQueue是同步队列，因此会在池中寻找可用线程来执行，若有可以线程则执行，若没有可用线程则创建一个线程来执行该任务；若池中线程空闲时间超过指定大小，则该线程会被销毁。
- 适用：执行很多短期异步的小程序或者负载较轻的服务器
newFixedThreadPool：
- 底层：返回ThreadPoolExecutor实例，接收参数为所设定线程数量nThread，corePoolSize为nThread，maximumPoolSize为nThread；keepAliveTime为0L(不限时)；unit为：TimeUnit.MILLISECONDS；WorkQueue为：new LinkedBlockingQueue<Runnable>() 无解阻塞队列
- 通俗：创建可容纳固定数量线程的池子，每隔线程的存活时间是无限的，当池子满了就不在添加线程了；如果池中的所有线程均在繁忙状态，对于新任务会进入阻塞队列中(无界的阻塞队列)
- 适用：执行长期的任务，性能好很多
newSingleThreadExecutor:
- 底层：FinalizableDelegatedExecutorService包装的ThreadPoolExecutor实例，corePoolSize为1；maximumPoolSize为1；keepAliveTime为0L；unit为：TimeUnit.MILLISECONDS；workQueue为：new LinkedBlockingQueue<Runnable>() 无解阻塞队列
- 通俗：创建只有一个线程的线程池，且线程的存活时间是无限的；当该线程正繁忙时，对于新任务会进入阻塞队列中(无界的阻塞队列)
- 适用：一个任务一个任务执行的场景
NewScheduledThreadPool:
- 底层：创建ScheduledThreadPoolExecutor实例，corePoolSize为传递来的参数，maximumPoolSize为Integer.MAX_VALUE；keepAliveTime为0；unit为：TimeUnit.NANOSECONDS；workQueue为：new DelayedWorkQueue() 一个按超时时间升序排序的队列
- 通俗：创建一个固定大小的线程池，线程池内线程存活时间无限制，线程池可以支持定时及周期性任务执行，如果所有线程均处于繁忙状态，对于新任务会进入DelayedWorkQueue队列中，这是一种按照超时时间排序的队列结构
- 适用：周期性执行任务的场景
线程池任务执行流程：
- 当线程池小于corePoolSize时，新提交任务将创建一个新线程执行任务，即使此时线程池中存在空闲线程。
- 当线程池达到corePoolSize时，新提交任务将被放入workQueue中，等待线程池中任务调度执行
- 当workQueue已满，且maximumPoolSize>corePoolSize时，新提交任务会创建新线程执行任务
- 当提交任务数超过maximumPoolSize时，新提交任务由RejectedExecutionHandler处理
- 当线程池中超过corePoolSize线程，空闲时间达到keepAliveTime时，关闭空闲线程
- 当设置allowCoreThreadTimeOut(true)时，线程池中corePoolSize线程空闲时间达到keepAliveTime也将关闭
4.继承 Thread 类并使用 isAlive() 方法来检测一个线程是否存活：
5.
top –hv | -abcHimMsS –d delay –n iterations –p pid [, pid …]
top程序提供运行系统的动态实时视图，它可以显示系统概要信息以及当前由Linux内核当前管理的任务列表。所示的系统概要信息的类型以及为任务显示的信息的类型、顺序和大小都是用户可配置的，并且可以在重新启动时使配置保持不变。
Linux top命令用于实时显示 process 的动态。
使用权限：所有使用者。
6
MySQL有三种锁的级别：页级、表级、行级。
表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
解除正在死锁的状态有两种方法：
第一种：
1.查询是否锁表
show OPEN TABLES where In_use > 0;
2.查询进程（如果您有SUPER权限，您可以看到所有线程。否则，您只能看到您自己的线程）
show processlist
3.杀死进程id（就是上面命令的id列）
kill id
第二种：
1.查看下在锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;
2.杀死进程id（就是上面命令的trx_mysql_thread_id列）
kill 线程ID
原文链接：https://blog.csdn.net/tr1912/article/details/81668423
7.cross join 是笛卡儿乘积 就是一张表的行数乘以另一张表的行数
right join 第二张表的连接列在第一张表中没有匹配是,第一张表中的值返回null
full join 返回两张表中的行 left join+right join
inner join 只返回两张表连接列的匹配项
- 建立索引：
- 存储特点：
- 聚集索引。表数据按照索引的顺序来存储的，也就是说索引项的顺序与表中记录的物理顺序一致。对于聚集索引，叶子结点即存储了真实的数据行，不再有另外单独的数据页。 在一张表上最多只能创建一个聚集索引，因为真实数据的物理顺序只能有一种。
- 非聚集索引。表数据存储顺序与索引顺序无关。对于非聚集索引，叶结点包含索引字段值及指向数据页数据行的逻辑指针，其行数量与数据表行数据量一致。
| 隔离级别 | 脏读 | 非重复读 | 幻像读 |
| read uncommitted | 允许 | 允许 | 允许 |
| read committed | 允许 | 允许 | |
| repeatable read | 允许 | ||
| serializable |
10.redis 本身是单线程所以是线程安全的，但是不代表业务就是线程安全的，所以要是用redis 的分布式锁
11.
明确了优化目标之后，我们需要确定达到我们目标的方法。对于 SQL 语句来说，达到上述2个目标的方法其实只有一个，那就是改变 SQL 的执行计划，让他尽量“少走弯路”，尽量通过各种“捷径”来找到我们需要的数据，以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标。
尽量少 join
MySQL 的优势在于简单，但这在某些方面其实也是其劣势。MySQL 优化器效率高，但是由于其统计信息的量有限，优化器工作过程出现偏差的可能性也就更多。对于复杂的多表 Join，一方面由于其优化器受限，再者在 Join 这方面所下的功夫还不够，所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。但如果是简单的单表查询，这一差距就会极小甚至在有些场景下要优于这些数据库前辈。
尽量少排序
排序操作会消耗较多的 CPU 资源，所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL 的响应时间。
对于MySQL来说，减少排序有多种办法，比如：
通过利用索引来排序的方式进行优化
减少参与排序的记录条数
非必要不对数据进行排序
Select * 一般都会造成全表扫描，显示所有列，select 需要的字段即可。
尽量用 join 代替子查询
虽然 Join 性能并不佳，但是和 MySQL 的子查询比起来还是有非常大的性能优势。MySQL 的子查询执行计划一直存在较大的问题，虽然这个问题已经存在多年，但是到目前已经发布的所有稳定版本中都普遍存在，一直没有太大改善。虽然官方也在很早就承认这一问题，并且承诺尽快解决，但是至少到目前为止我们还没有看到哪一个版本较好的解决了这一问题。
尽量用 union all 代替 union：
union 和 union all 的差异主要是前者需要将两个(或者多个)结果集合并后再进行唯一性过滤操作，这就会涉及到排序，增加大量的 CPU 运算，加大资源消耗及延迟。所以当我们可以确认不可能出现重复结果集或者不在乎重复结果集的时候，尽量使用 union all 而不是 union。
禁用外键
一个SQL只能在一个cpu上运行
高并发环境中，大SQL容易影响性能问题
可能一个大SQL把数据库搞死
拆分SQL
保持事物的短小精悍
即开即用，用完即关
无关操作踢出事务，减少资源占用
保持一致性的前提下，拆分事务
避免大批量更新
避开高峰
白天限制速度
加sleep
避免类型转换
避免取过量数据，建议使用limit
避免在SQL 语句中进行数学运算、函数计算、逻辑判断等操作
避免OR
同一字段，推荐in
不同字段，推荐union
优先优化高并发的 SQL，而不是执行频率低某些“大”SQL
从全局出发优化，而不是片面调整
尽可能对每一条运行在数据库中的SQL进行explain。
-------------------------------------------------------------
2.使用唯一索引，考虑某列中值的分布。对于惟一值的列，索引的效果最好，而具有多个重复值的列，其索引效果最差。
3.使用短索引。如果对串列进行索引，应该指定一个前缀长度，只要有可能就应该这样做。例如，如果有一个CHAR(200) 列，如果在前10 个或20 个字符内，多数值是惟一的，那么就不要对整个列进行索引。对前10 个或20 个字符进行索引能够节省大量索引空间，也可能会使查询更快。
4.利用最左前缀。在创建一个n 列的索引时，实际是创建了MySQL可利用的n 个索引。多列索引可起几个索引的作用，因为可利用索引中最左边的列集来匹配行。这样的列集称为最左前缀。
5.不要过度索引。不要以为索引“越多越好”，什么东西都用索引是错的。每个额外的索引都要占用额外的磁盘空间，并降低写操作的性能，这一点我们前面已经介绍 过。在修改表的内容时，索引必须进行更新，有时可能需要重构，因此，索引越多，所花的时间越长。如果有一个索引很少利用或从不使用，那么会不必要地减缓表 的修改速度。此外，MySQL在生成一个执行计划时，要考虑各个索引，这也要费时间。创建多余的索引给查询优化带来了更多的工作。索引太多，也可能会使 MySQL选择不到所要使用的最好索引。只保持所需的索引有利于查询优化。如果想给已索引的表增加索引，应该考虑所要增加的索引是否是现有多列索引的最左 索引。如果是，则就不要费力去增加这个索引了，因为已经有了。