Add some notes to Reusing Redis Connections

Help avoid pitfalls with closing reused connections and keyPrefix.

Fix for OptimalBits#1747

PATTERNS.md

@@ -66,7 +66,12 @@ The most robust and scalable way to accomplish this is by combining the standard
 Reusing Redis Connections
 -------------------------
 
-A standard queue requires **3 connections** to the Redis server. In some situations you might want to re-use connections—for example on Heroku where the connection count is restricted. You can do this with the `createClient` option in the `Queue` constructor (note: bclient connections [cannot be re-used](https://github.com/OptimalBits/bull/issues/880)):
+A standard queue requires **3 connections** to the Redis server. In some situations you might want to re-use connections—for example on Heroku where the connection count is restricted. You can do this with the `createClient` option in the `Queue` constructor.
+
+Notes:
+- bclient connections [cannot be re-used](https://github.com/OptimalBits/bull/issues/880), so you should return a new connect each time this is called. These connections will be disconnected/reconnected by bull automatically as part of queue operations and will be disconnected when the queue is closed
+- client and subscriber connections can be shared and will not be closed when the queue is closed.  When you are shutting down the process, first close the queues, then the shared connections (if they are shared).  If you are not sharing client and subscriber connections but using `createClient` to do some custom connection logic, you will need to keep a list of all the connections you created so you can manually close them later when the queue shuts down
+- do not set a `keyPrefix` on the connection you create, use bull's built-in prefix feature if you need a key prefix
 
 ```js
 var {REDIS_URL} = process.env