Hi Chris, without specifics of the particular app I can only speak in general terms.
In principle the idea of caching is about re-using the output of a process without incurring the cost of processing that went into creating that output in the first place. This can range from a browser grabbing content from your local computer without making another request to the server, through a server holding data in RAM to avoid the costs of fetching it from disk (or from a DB process or query) to an algorithm holding data that it'll need later to avoid the cost of re-calculations to get the same data.
Now memcache and redis are two of various in-memory data stores. In the case of these two the stores are simple key/value pairs, although you can make the value as complicated as you like. An example use case is a website that needs to be displayed in different languages and where the translated texts are stored in a database - in such a case it is far better to 'cache' the translations in an in-memory store like memcahe or redis to speed up look ups compared to making DB queries. Of course some of these stores do far more than just storing key/value data.
By MQ did you mean 'Message Queue' ? These systems are designed for (distributed) messaging of one sort or another - be it inter-process or ordinary messaging from computer to human recipients. In the case where a process is queuing up messages (commands) for another process, this can be considered caching.
If your interest in caching is to optimize an app, it is worth remembering that optimization needs to be looked at end to end, not just at the point of delivery (eg browser) Maybe the way the content is stored needs to be looked at, maybe the processes that put the content together for delivery need to be optimized, might content delivery networks (CDNs) help, are images optimized, etc etc etc ?
Hope that gave you some pointers and food for thought ...