add GetItems method

[DoubleDi]

Hi! @ReneKroon !
Awesome cache!
Want to switch to yours from https://github.com/patrickmn/go-cache as yours has a size limit.

Can you accept a small PR which adds the GetItems method?

[ReneKroon]

I think it's a good function. However i think it's more correct to call getItem on each individual key? That way all ttl related operations and notifications are respected.

[DoubleDi]

@ReneKroon are you sure we should update all the TTL on this handler? getItem updates the TTL if skipTTLExtension is not true. IMHO GetItems() is a META handler, which does not indicate, that the element was actually retrieved. But will honour your decision on this one

Also planing on other PR:

1. refactor mutex to rwmutex
2. add a parameter which will specify how often to do the startExpirationProcessing loop. Currently it is hardcoded to 1 hour.

Will you support and accept those?

[ReneKroon]

On the other PR proposals:

there is one outstanding PR that attempts this but fails (#58) on 'refactor mutex to rwmutex'. This is however very tricky since a 'get' can also modify TTL values. Note that @chenyahui made several other great performance improvements, but this one is way harder. But if you can make it work, go for it.

The startExpirationProcessing should be adjusted automatically when items with a lower TTL than the next processing loop are inserted. Did you find a case where this is not happening?

[DoubleDi]

Got you! Will see what I can do.

About the expire loop timer. If the cache ttl is more than 1 hour (ex 24 hours), the loop will only run once every 24 hours. Not sure if that is a must to change that.

What about the current PR? Should I change to getItem or keep as is?

[ReneKroon]

Please use the 'getItem' in the call so that the interface has consistent behavior.

[DoubleDi]

Done

[ReneKroon]

apologies for the crappy Travis build, it's having issues with a code coverage token on master branches in forks.