так как MDC статический класс данные перезаписывались и снова каша
Это не так - MDC использует ThreadLocal, поэтому значения в нем для каждого потока свои собственные, поэтому в лог файле для каждого сообщения будет выведен именно тот самый ид, который был указан в MDC именно для того потока, который сообщение и породил.
Каша, скорее всего, возникает просто от того, что параллельные потоки пишут параллельно и в итоге в логах записи каждой конкретной сессии не идут все подряд, а перемежаются с другими сессиями.
Но это совершенно нормально для логов в параллельной среде. Ид сессии в логи добавляют вовсе не для упорядочивания, а для того, чтобы потом было легко извлечь логи, относящиеся к определенной сессии. В простейшем варианте это делается через
grep %session% file.log. Если система порождает множество ращнообразныз логов, то применяют системы вроде Splunk для упрощения поиска по множеству файлов и организации всех логов в единую базу.
log4j.appender.asyncLog=com.log.AsyncAppenderHelper
ПОможет ли он?
Интересно почему какой-то сторонний класс (судя по пакету), а не AsyncAppender из самого log4j.
Но тем не менее, это не поможет: задача, которую решают AsyncAppender-ом - это накапливать сообщения в памяти и потом пачкой записывать их на диск (RollingFileAppender - это синхронный appender и он пишет все сообщения в файл сразу же). Порядок сообщений при использовании AsyncAppender никак не меняется - они по прежнему идут в том порядке, в каком было порождены.