Если у вас меньше узлов, чем запрошенных копий данных, вы не сможете получить все запрошенные копии данных.
Например, backup-count=2 запрашивает 3 копии данных, основную и две резервные копии. Если есть только 2 узла, то вы не можете разместить 2-ую резервную копию где-либо. Для узла не имеет смысла размещать более одной копии - смысл этого заключается в безопасности данных, сбой узла должен привести к потере только одной копии.
Если вы записываете 20 записей по 1 МБ, то это 20 МБ за копию. У вас 1 узел, поэтому 1 копия, поэтому 20 МБ.
У вас не будет резервных копий, поскольку их негде разместить. Но если вы это сделаете, они будут включены в расчет максимального размера.
Для вашего примера, если у вас было 4 узла, 1 резервная копия (всего 2 копии) и 20 записей, можно ожидать, что каждый узел будет иметь 5 из записей первичной копии и 5 записей резервной копии, поэтому имеют 10 МБ данных. 40 МБ данных распределены по 4 узлам. Фактическое распределение зависит от ключей, которые могут быть неоднородными.
Все это можно подтвердить в центре управления. Это неплохая идея, так как часто то, что считается записью 1 МБ, на самом деле имеет другой размер после сериализации и допускает накладные расходы.
Это https://docs.hazelcast.org/docs/4.0/manual/html-single/index.html#map -эвикт объясняет, как работает выселение.