fix style: Storm开发过程问题小结-2.md

1 files changed, 12 insertions, 12 deletions

diff --git a/Storm开发过程问题小结-2.md b/Storm开发过程问题小结-2.md
index e2fc0e4..38c30a3 100644
--- a/Storm开发过程问题小结-2.md
+++ b/Storm开发过程问题小结-2.md
@@ -1,21 +1,21 @@
 ## Storm 开发过程问题小结
 ### 1. Storm 资源文件 or 配置文件正确读取
 
-__资源文件__主要指一些偏向为程序提供数据的文件，一般文件内容较多，文件大小比较大，比如说批量的IP列表or域名列表；__配置文件__主要指一些程序需要的参数配置，或者是文件名等比较短的数据，比如说统计时间、使用的数据库相关配置等【在我这里】。
+__资源文件__ 主要指一些偏向为程序提供数据的文件，一般文件内容较多，文件大小比较大，比如说批量的IP列表or域名列表； __配置文件__ 主要指一些程序需要的参数配置，或者是文件名等比较短的数据，比如说统计时间、使用的数据库相关配置等【在我这里】。
 
-因为 Storm 采用分布式集群，存在多台服务器，而这些__资源文件和配置文件是需要同代码文件一起，放在同一台服务器上__，所以在部署 jar 包到远端的时候需要注意资源文件和配置文件能够在该台服务器上找到，否则就会出现文件不存在的错误。
+因为 Storm 采用分布式集群，存在多台服务器，而这些 __资源文件和配置文件是需要同代码文件一起，放在同一台服务器上__ ，所以在部署 jar 包到远端的时候需要注意资源文件和配置文件能够在该台服务器上找到，否则就会出现文件不存在的错误。
 
-资源文件or配置文件的存放位置一般可以分为两种，__ jar 包内__ or __jar 包外__。
+资源文件or配置文件的存放位置一般可以分为两种， __jar 包内__ or __jar 包外__ 。
 
-如果放在 jar 包外，那么当把 jar 包上传到 storm 中部署时，就需要__利用 pscp 工具__批量拷贝资源文件到所有的 storm 集群服务器上，一旦资源文件 or 配置文件的参数需要修改时，就__需要再次批量拷贝覆盖__所有服务器上的文件。个人认为过于麻烦【之前写 C 的时候没办法，只能采用这种方式，__可以把部署的 IP 以及命令整合成 shell 脚本，直接运行 shell 脚本__，也还行】。
+如果放在 jar 包外，那么当把 jar 包上传到 storm 中部署时，就需要 __利用 pscp 工具__ 批量拷贝资源文件到所有的 storm 集群服务器上，一旦资源文件 or 配置文件的参数需要修改时，就__需要再次批量拷贝覆盖__所有服务器上的文件。个人认为过于麻烦【之前写 C 的时候没办法，只能采用这种方式，__可以把部署的 IP 以及命令整合成 shell 脚本，直接运行 shell 脚本__ ，也还行】。
 
 **建议直接放在 jar 包内部**，直接把相关的文件，__放在 resources 中__，然后利用上次提到的命令 `InputStream is = this.getClass().getClassLoader().getResourceAsStream("dns_demo.txt")`  去获取 resources 中的文件，这个例子命令的这个 `dns_demo.txt` 就是直接放在 resources 下，如果 resources 存在子文件夹 `data` ，则上面命令括号中变成 `data/dns_demo.txt` 即可。
 
 如果资源文件和配置文件放在 jar 包内部【之前我一直以为文件打包入 jar 包之后，就不能修改其内容，每次想要修改内容时都需要重新打包，后来询问钊哥了解到自己理解错误】，当想要修改某个配置参数时，参考 [这里](https://blog.csdn.net/luckykapok918/article/details/82883967) __可以通过 vim 命令直接编辑 jar 包中的文件__【`vim xxx.jar 回车`：首先会列出全部文件；然后输入`/xxx 回车` 来进行检索文件名，定位到对应的 xxx 文件；然后直接 `回车` 进入配置文件内进行编辑；最后输入 `:wq 回车` 保存退出即可】。
 
-__坑：__之前读取文件时，在网上还搜了个代码 `URLDecoder.decode(this.getClass().getResource("/data/RTDNS.txt").getPath(), "UTF-8")` ，直接贴上了，在本机测试时，能够读取 resources 下面的文件，运行也没有问题；然后部署到华严的 storm 集群上，运行也十分OK，能够找到该资源文件，正确运行；结果到了科技网上的 storm 集群，**完全同样的代码**，它就不好使了，找到的文件路径错误，感觉是在 `/data/RTDNS.txt` 之前多了一个 `!` 感叹号。
+__坑：__ 之前读取文件时，在网上还搜了个代码 `URLDecoder.decode(this.getClass().getResource("/data/RTDNS.txt").getPath(), "UTF-8")` ，直接贴上了，在本机测试时，能够读取 resources 下面的文件，运行也没有问题；然后部署到华严的 storm 集群上，运行也十分OK，能够找到该资源文件，正确运行；结果到了科技网上的 storm 集群，**完全同样的代码**，它就不好使了，找到的文件路径错误，感觉是在 `/data/RTDNS.txt` 之前多了一个 `!` 感叹号。
 
-__解决方案：__最后把所有读取文件的地方，全部改成 `InputStream is = this.getClass().getClassLoader().getResourceAsStream("dns_demo.txt")` 这种形式，最后科技网那边就好使了……
+__解决方案：__ 最后把所有读取文件的地方，全部改成 `InputStream is = this.getClass().getClassLoader().getResourceAsStream("dns_demo.txt")` 这种形式，最后科技网那边就好使了……
 
 __参考资料：__
 
@@ -33,11 +33,11 @@ __参考资料：__
 
 ### 2. storm 架构原理及并行度理解
 
-主要是在添加公开域名后缀 API 使用时，本机 json 文件读取输出时 OK ，但是远端部署到华严后，同样的代码，就是跑不出来结果【由于当时还没有 get 到利用远端 storm 运行日志检查来分析出错的技能，所以__一度怀疑是添加的这个 API 的线程安全，在 storm 分布式的场景下存在一些问题__，由此调研学习了一堆下面的相关资料，但还是没有解决；最后采取的方案是换了另外一种 API ，虽然此 API 对域名格式的校验更为严格，但是至少华严集群跑的时候不会出问题】
+主要是在添加公开域名后缀 API 使用时，本机 json 文件读取输出时 OK ，但是远端部署到华严后，同样的代码，就是跑不出来结果【由于当时还没有 get 到利用远端 storm 运行日志检查来分析出错的技能，所以 __一度怀疑是添加的这个 API 的线程安全，在 storm 分布式的场景下存在一些问题__ ，由此调研学习了一堆下面的相关资料，但还是没有解决；最后采取的方案是换了另外一种 API ，虽然此 API 对域名格式的校验更为严格，但是至少华严集群跑的时候不会出问题】
 
 __参考资料：__
 
-- [这篇讲并行度讲得算是比较通俗易懂](https://blog.csdn.net/qq_37095882/article/details/77624340)：没有设置并行度和worker数量时，__默认分配一个worker__，__每个spout或bolt各占一个线程，各自并行度为1__；读取数据的并行度为4，最终统计结果应该就是原来的4倍；另外，__输入和输出的汇总型bolt的并行度只能设置为1，以保证结果的可靠性__；【看起来__worker的个数并不影响最终的结果__，是storm自身的机制（__zookeeper保证storm节点之间的信息通信__）__保证了多个worker执行同一个topo时，能够协同合作__】；多worker情况下线程的分配也是根据并行度来的；__同一个topo的多个worker可能运行在不同的节点supervisor上__。
+- [这篇讲并行度讲得算是比较通俗易懂](https://blog.csdn.net/qq_37095882/article/details/77624340)：没有设置并行度和worker数量时，__默认分配一个worker__，__每个spout或bolt各占一个线程，各自并行度为1__；读取数据的并行度为4，最终统计结果应该就是原来的4倍；另外，__输入和输出的汇总型bolt的并行度只能设置为1，以保证结果的可靠性__；【看起来 __worker的个数并不影响最终的结果__，是storm自身的机制（__zookeeper保证storm节点之间的信息通信__ ）__保证了多个worker执行同一个topo时，能够协同合作__】；多worker情况下线程的分配也是根据并行度来的；__同一个topo的多个worker可能运行在不同的节点supervisor上__。
 
 ![没有设置并行度和worker数量时，默认分配一个worker，每个spout或bolt各占一个线程，各自并行度为1](images/20191011112344210_5647.png)
 ![并行度](images/20191011112153513_11708.png)
@@ -45,7 +45,7 @@ __参考资料：__
 ![多worker情况下线程的分配](images/20191011112706558_32284.png)
 ![同一个topo的多个worker可能运行在不同的节点supervisor上](images/20191011112822973_7758.png)
 
-- [为什么不同supervisor上的同一个topology的worker还能够执行一个任务而保证一致性呢？](https://zhuanlan.zhihu.com/p/25414207)：是__利用zookeeper获得相同的心跳和信息__
+- [为什么不同supervisor上的同一个topology的worker还能够执行一个任务而保证一致性呢？](https://zhuanlan.zhihu.com/p/25414207)：是 __利用zookeeper获得相同的心跳和信息__
 
 ![利用zookeeper获得相同的心跳和信息](images/20191011113823017_17192.png)
 
@@ -72,15 +72,15 @@ __参考资料：__
 
 #### 坑：严格来说不是 storm 的锅，应该是 storm+mysql 的锅
 
-__问题描述：__本地读取 json 文件入的数据库和在华严部署 storm 上入的是__完全相同的一个数据库，本地运行OK，但远程 storm 死活无法入库__，查看 storm 日志后发现如下图：
+__问题描述：__ 本地读取 json 文件入的数据库和在华严部署 storm 上入的是 __完全相同的一个数据库，本地运行OK，但远程 storm 死活无法入库__，查看 storm 日志后发现如下图：
 
 ![](images/20191012214532590_10206.png)
 
 查了一堆后发现，其实是登录 mysql 的主机对应的密码不对，才出现了这个问题。而为什么本地登录密码正确，而远程登录密码就错误了呢？明明是相同的用户名和密码。
 
-__解决方案：__原因是 __mysql 这边登录数据库时，不仅只检查用户名和密码，还会检查登录的 host 主机名/IP地址__。然后检查 10 上 mysql 数据库的用户表发现，本地登录时，host 是 '%' 表示任意 host 均可登录；而__远程登录的时候，用户表中存在  host 为 'master' 的项__，而 storm 登录的时候，就得走这个接口进行密码检查，结果密码出错。最后在 mysql 中运行 `GRANT ALL PRIVILEGES ON *.* TO 'root'@'master' IDENTIFIED BY '111111' WITH GRANT OPTION;` 把 mater 这个 host 对应的密码改成同配置中的一样，最后运行 OK 。
+__解决方案：__ 原因是 __mysql 这边登录数据库时，不仅只检查用户名和密码，还会检查登录的 host 主机名/IP地址__。然后检查 10 上 mysql 数据库的用户表发现，本地登录时，host 是 '%' 表示任意 host 均可登录；而 __远程登录的时候，用户表中存在  host 为 'master' 的项__，而 storm 登录的时候，就得走这个接口进行密码检查，结果密码出错。最后在 mysql 中运行 `GRANT ALL PRIVILEGES ON *.* TO 'root'@'master' IDENTIFIED BY '111111' WITH GRANT OPTION;` 把 mater 这个 host 对应的密码改成同配置中的一样，最后运行 OK 。
 
-__经验收获：__认真看运行日志，里面藏着非常非常多的信息！！！
+__经验收获：__ 认真看运行日志，里面藏着非常非常多的信息！！！
 
 __参考资料：__