Not every problem is best solved with (existing) design patterns. You'd be surprised at the number of programs that were developed before the release of the Design Patterns book by the Go4.
That said, while multithreading wasn't as hot a topic at the time the aforementioned book was released as it is now, I'm sure many patterns can be reasonably applied to certain areas of a multithreaded application. However, just like the run-off-the-mill products you can cheaply buy everywhere are designed to be useful for the average user, design patterns are best used in a context with average requirements.
You have a strong requirement, i. e. implementing a high-performance system, and such requirements always need to be tailored to the specific problem and cicumstances! You may be able to adapt a design pattern to your requirements, but without knowing what, exactly, those requirements are, it's impossible to say if that is actually worth your while. Most likely, you'll be better off not wasting time on hammering a round-peg-pattern into a square-hole-problem*!
Start by writing down the functional requirements (e. g. able to handle requests of type X), non-functional requirements (e. g. able to handle at least 650 requests per second (if you don't write down a hard number in the requirements then you won't know when to stop optimizing!)), then consider the type of objects you deal with, the individual entities (client, server, proxy, whatever) that need to communicate with each other, and then consider communication protocols.
Once you're there, you'll have a better idea about how much information (in bytes) needs to be processed, how much time there is to do the job, and whether all of the entities actually need to be multithreaded at all. You seem to be taking this as granted or even part of the requirement - but it is purely a design decision, and other requirements (such as transaction safety) may in fact be directly opposed to the idea of multithreading. (not that it can't be done, just that it's so much harder to implement, it's not worth your time).
Maybe you'll find that there is so little data overall that you can easily process it in a single-threaded program. Maybe you'll find there is so much to process that the hardware you have is incapable to pass the information along, let alone process it. (In that case it's time to scrutinize the requirements and see which parts can be toned down to a more practical level.)
In short, there is no recipe book for parallel programming of any kind, mostly because it is a complex field, and only required in very specialized applications that require specialized solutions.
*: in truth, real world projects are neither square nor round: they're more like asteroids or comets - of irregular shape, speckled with craters caused by the many requirements fired at it over time, and filled with rare elements. But once they enter the atmosphere, they start disassembling into more managable bits. And that is for the better, because otherwise they would inevitably crash, leaving dead programmers in their wake.
Submit an article or tip