1) nginx禁止對寫操作timeout時retry

以前遇到的一個case，業務那邊說一筆請求從nginx端發送給后端tomcat了2次（落在兩個不同的tomcat節點上）。
后來發現是nginx發給后端節點timeout，然后做了重試，發給了另一個節點。
默認情況下nginx對后端error和 timeout 都會做retry，可以明確的禁止在timeout的情況下禁止retry。
當然如果集群讀寫分離的話，對于只讀集群retry是無所謂的，但對于寫確實存在問題。

2) kafka重啟時因為數據日志文件名被人重命名過而導致啟動失敗

啟動kafka broker的時候，會重新load之前的每個topic的數據，正常情況下會提示每個topic恢復完成。

INFO Recovering unflushed segment 588022 in log xxx-topic-0. (kafka.log.Log) INFO Completed load of log xxx-topic-0 with log end offset 590676 (kafka.log.Log)

但當有些topic下的數據恢復失敗的時候，會導致broker關閉，異常如下

ERROR There was an error in one of the threads during logs loading: java.lang.NumberFormatException: For input string: "test" (kafka.log.LogManager) FATAL [Kafka Server 3], Fatal error during KafkaServer startup. Prepare to shutdown (kafka.server.KafkaServer)java.lang.NumberFormatException: For input string: "test"at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)at java.lang.Long.parseLong(Long.java:589)at java.lang.Long.parseLong(Long.java:631)at scala.collection.immutable.StringLike$class.toLong(StringLike.scala:251)at scala.collection.immutable.StringOps.toLong(StringOps.scala:30)at kafka.log.Log$$anonfun$loadSegments$4.apply(Log.scala:152)at kafka.log.Log$$anonfun$loadSegments$4.apply(Log.scala:141)at scala.collection.TraversableLike$WithFilter$$anonfun$foreach$1.apply(TraversableLike.scala:778)at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:33)at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:186)at scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:777)at kafka.log.Log.loadSegments(Log.scala:141)at kafka.log.Log.<init>(Log.scala:67)at kafka.log.LogManager$$anonfun$loadLogs$2$$anonfun$3$$anonfun$apply$7$$anonfun$apply$1.apply$mcV$sp(LogManager.scala:142)at kafka.utils.Utils$$anon$1.run(Utils.scala:54)at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)at java.util.concurrent.FutureTask.run(FutureTask.java:266)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at java.lang.Thread.run(Thread.java:745)

這是因為某個目錄下，存在一個 test.log 的文件

$ ls mytopic-0/ 00000000000000000485.index 00000000000000000485.log 00000000000000000568.index 00000000000000000568.log test.log

看上去這個 test.log 當時是把 00…log 給拷貝了一個，然后用編輯器去查看內容。而事后忘了清理掉，導致重啟時把這個文件當成一個畸形文件了。因為kafka broker要求所有數據文件名稱都是Long類型的。

3) 又一個actor阻塞的例子

在我自己的mac上測試的時候，一切正常，部署到dev環境就嚴重超時。
jstack觀察發現又是誤用阻塞操作導致所有actor的線程都被阻塞所致，當時?EventProcessor?這個 Router 背后的實例數設置的是40，而這臺dev環境的linux只有2核，根據當時akka的配置里的并發因子算出并發線程數是32，
所以32個線程基本都被 eventProcessor 的40個actor全給占用了，因為它是不斷發消息輪詢的（我的mac是8核，運行時的線程數要大于40不會發生全部被阻塞的情況）。
解決方式，一方面調大并發因子，把線程數提升上去，另一方面控制 eventProcessor 的實例數，不讓它的阻塞操作影響到其他actor。(其實根上是沒設計好，沒有隔離阻塞操作，只不過這正好是個小應用，不需要過多考慮。)

?

http://hongjiang.info/untitled-2/

?

轉載于:https://www.cnblogs.com/softidea/p/9724747.html

總結

以上是生活随笔為你收集整理的nginx禁止对写操作timeout时retry的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。