开头
最近服务器搞的有点多，突然想尝试一下
中间
-
收集密码字典，去重加入数据库中，id自增，字段越少越好
- 为了速度，是否可以把数据库从云迁移到本地？
- 考虑到每次尝试，其实是发送一个请求，并且为了减少封禁概率，应该不会特别快的频率
- 其实还是可用
-
利用xxljob进行分片，
- 先把账号密码放在数据库当中，按照分页的方式去获取账号密码
-
单独一个微服务提供ip池子
- 已分配的ip在池子中标记为锁定
- 话说，即使放回去，下一个应用去使用，不也一样会被使用 最好的办法是，用过的ip往后排，轮询，优先使用没用过的ip
- 那么可以使用redis的zset，选择score小的，score小说明用的少
- 每次使用根据score排序，最后我们总是取score最小的那个即可
-
提供一个策略，以网站域名为key，对应的发送策略为值，避免重复编写代码
-
xxljob启动任务时，需要指定网站域名
-
具体这个账号，是采用数字，还是字符，怎么查询这部分账号，由具体的策略来决定
-
-
如果任务执行到一半停止了，怎么标记这个 账号 和 名字 已经试过，不行？
- 其实可以记录下，当前这个主机，它的账号执行到哪一页，密码执行到哪一页
- 然后我们新增数据库数据时总是按照自增id，或者时间自增，这样的排序
- 那么就可以保证不会进行重复匹配了
-
怎么标记这个主机呢？
- 我们这里唯一的标识符，应该采用ip，ip才是唯一的，xxljob的分片序号感觉不靠谱
- 我们查询分片时，首先要从数据库中查询，看上次是否有没做完的数据
- 如果有，则采用数据库的分页数
- 如果没有，则采用xxljob的分片数，然后再持久化到数据库
-
账号 和 密码 要进行 全排列 吗？
- 如果要全排列，那么账号和域名，怎么进行分片？
- 1-10 的账号 与 1-10 的密码 给A匹配
-
11-20 的账号 与 11-20的密码 给B匹配 ...
-
这有个问题，1-10的账号没有与11-20的密码进行匹配过
-
那么应该是，1-10的账号与所有密码进行对应，交给A 11-20的账号与所有密码进行对应，交给B
-
所以我们的分片其实是按照账号数进行分片的
-
考虑到这个爆破运行时长会非常长，那么应该要保证好：
- 长时间运行的稳定
-
出意外宕机时，要记录一下已匹配过的页数
- 这个其实可以通过：每执行完一页的账号密码，就去更新一次数据库 这样再差再差，也就重复一页的数据 还可以减少一页大小，避免出现过多的丢失
-
应当是可以暂停的
- 那么应该有一个保护性暂停模式 是否可以考虑用futureTask，它里面是否有保护性暂停呢？
-
提供一个接口，调用后暂停
-
应当有一个页面，记录每个主机，现在执行到了哪一页，成功数多少，已尝试多少，主机的运行状态如何
-
应该有一个库，去记录匹配成功的账号
- 怎么样是匹配成功的响应？应该由策略决定
-
应当保持精简，占用内存越少越好
- 但是作为执行器项目，必定是需要一个springboot，无法避免了
-
为了充分利用核心，应当支持多线程
- 线程数：使用核心数，作为线程池。默认forkjoinPool 就是这样的设置
- 分片问题：
- 使用多线程之后，数据分片该怎么做？
- 可以这样，一次获取100条数据
- 然后每个线程去分配这100条数据，每个线程单独获取一个ip
- 只读，不会涉及到线程安全问题，可见性可以用volatile解决
- 等所有子线程执行完毕后，再获取下一次的数据
-
请求响应的记录
- 不应该所有响应都记录
- 但是应该记录一定数量的日志
- 可以预见的是，请求的响应应当是重复，且类似的。
- 那么针对单个网站，我们其实可以对响应进行去重，具体的日志只记录响应的id
- 由于数据量较大，可以在本地做一层缓存，定时同步，找不到该响应，再向数据库发起请求
-
可以参考现有开源分布式爬虫进行改造
结尾
没了
